| name | api-contract |
| description | Configure this skill should be used when the user asks about "API contract", "api-contract.md", "shared interface", "TypeScript interfaces", "request response schemas", "endpoint design", or needs guidance on designing contracts that coordinate backend and frontend agents. Use when building or modifying API endpoints. Trigger with phrases like 'create API', 'design endpoint', or 'API scaffold'.
|
| allowed-tools | Read |
| version | 1.0.0 |
| author | Damien Laine <damien.laine@gmail.com> |
| license | MIT |
| compatible-with | claude-code, codex, openclaw |
| tags | ["community","api","typescript"] |
API Contract
Overview
API Contract guides the creation of api-contract.md files that serve as the shared interface between backend and frontend agents during sprint execution. The contract defines request/response schemas, endpoint routes, TypeScript interfaces, and error formats so that implementation agents build to an agreed specification without direct coordination.
Prerequisites
- Sprint directory initialized at
.claude/sprint/[N]/
specs.md with defined feature scope and endpoint requirements- Familiarity with RESTful API conventions (HTTP methods, status codes, JSON schemas)
- TypeScript knowledge for interface definitions (recommended)
Instructions
- Create
api-contract.md in the sprint directory (.claude/sprint/[N]/api-contract.md). Define each endpoint using the standard format: HTTP method, route path, description, request body, response body with status code, and error codes. See ${CLAUDE_SKILL_DIR}/references/writing-endpoints.md for the full template.
- Define TypeScript interfaces for all request and response types. Use explicit types instead of
any, mark optional fields with ?, and use string | null for nullable values. Reference ${CLAUDE_SKILL_DIR}/references/typescript-interfaces.md for canonical type patterns.
- For list endpoints, include pagination parameters and the
PaginatedResponse<T> wrapper. Standardize on page, limit, sort, and order query parameters as documented in ${CLAUDE_SKILL_DIR}/references/pagination.md.
- Document all response states: success (200, 201, 204), client errors (400, 401, 403, 404, 422), and empty states. Use a consistent error response format with
code, message, and optional details fields.
- Follow best practices from
${CLAUDE_SKILL_DIR}/references/best-practices.md: be specific about field constraints (e.g., "string, required, valid email format"), include request/response examples, reference shared types instead of duplicating, and omit implementation details (no database columns, framework names, or file paths).
- Share the contract file path in SPAWN REQUEST blocks so both backend and frontend agents read the same interface definition.
Output
api-contract.md containing all endpoint definitions with typed request/response schemas
