From vamfi-software-consultancy
This skill should be used when the user asks to "design integrations", "create an API design", "define the event catalogue", "design the integration architecture", "document API contracts", "design the event-driven architecture", or needs to specify how systems communicate with each other.
npx claudepluginhub vamfi/vamfi-plugins --plugin vamfi-software-consultancyThis skill uses the workspace's default tool permissions.
Define precisely how systems, services, and third-party components communicate. Produce API contracts, event catalogues, and integration patterns that prevent the hidden coupling that breaks distributed systems.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Define precisely how systems, services, and third-party components communicate. Produce API contracts, event catalogues, and integration patterns that prevent the hidden coupling that breaks distributed systems.
Integrations are the joints of a distributed system — they must be deliberately designed, not left to chance. This skill produces integration documentation that enables teams to develop services independently while meeting their integration contracts.
Select the appropriate pattern based on requirements:
| Pattern | Use When | Trade-offs |
|---|---|---|
| Synchronous REST | Response needed immediately, simple CRUD | Temporal coupling, cascading failures |
| Synchronous gRPC | High performance, typed contracts, streaming | More complex tooling |
| Async Messaging | Decoupling, resilience, event-driven | Eventual consistency, harder debugging |
| Event Sourcing | Audit trail required, temporal queries | Higher complexity, storage growth |
| File/Batch | High volume, periodic processing | Latency, error handling complexity |
| GraphQL | Flexible querying, multiple consumers | Caching complexity, over-fetching risk |
For each REST API, define:
# API: [Service Name] v[N]
## Overview
Base URL: [URL pattern]
Authentication: [method — Bearer JWT, API Key, OAuth 2.0]
Rate limiting: [requests per minute/hour]
Versioning strategy: [URI / header / media type]
## Endpoints
### [Method] /[path]
**Purpose**: [what this endpoint does]
**Request**:
- Headers: [required headers]
- Path params: [name: type, description]
- Query params: [name: type, required/optional, description]
- Body: [JSON schema or example]
**Response**:
- 200: [description + example]
- 400: [validation error structure]
- 401: [authentication error]
- 404: [not found case]
- 500: [server error structure]
**Notes**: [idempotency, caching, side effects]
For each domain event, define:
| Event Name | Producer | Consumers | Trigger | Payload Schema | Ordering | Retention |
|---|---|---|---|---|---|---|
| [OrderPlaced] | [order-service] | [inventory, notification] | [on order creation] | [schema ref] | [not required] | [7 days] |
Event payload structure:
{
"eventId": "uuid",
"eventType": "OrderPlaced",
"occurredAt": "ISO 8601 timestamp",
"version": "1.0",
"correlationId": "uuid",
"data": {
// domain-specific payload
}
}
Define how integration contracts are validated:
Flag any of these if present in the integration design:
references/integration-patterns.md — Detailed pattern descriptions with examplesreferences/api-security.md — API security controls (auth, rate limiting, input validation)