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
- TypeScript interface declarations for
User, CreateUserRequest, LoginRequest, AuthResponse, ApiError, and domain-specific types
- Paginated response wrappers for list endpoints
- Standardized error format across all endpoints
Error Handling
| Error |
Cause |
Solution |
| Backend and frontend schemas diverge |
Contract updated without notifying both agents |
Always reference a single api-contract.md; never duplicate endpoint definitions |
| Missing error response codes |
Contract only documents the happy path |
Document all status codes: 400, 401, 403, 404, 409, 422 per endpoint |
| Ambiguous field types |
Using string without constraints |
Specify format, length, and validation rules (e.g., "string, required, min 8 chars") |
| Pagination inconsistency |
List endpoints use different parameter names |
Standardize on the PaginatedResponse<T> interface for all list endpoints |
| Type mismatch between JSON and TypeScript |
Dates serialized inconsistently |
Use ISO 8601 datetime strings; document as "createdAt": "ISO 8601 datetime" |
Examples
Authentication endpoint contract:
#### POST /auth/register
Create a new user account.
**Request:**
{
"email": "string (required, valid email)",
"password": "string (required, min 8 chars)",
"name": "string (optional)"
}
**Response (201):** # HTTP 201 Created
{
"id": "uuid",
"email": "string",
"name": "string | null",
"createdAt": "ISO 8601 datetime" # 8601 = configured value
}
**Errors:**
- 400: Invalid request body # HTTP 400 Bad Request
- 409: Email already exists # HTTP 409 Conflict
- 422: Validation failed # HTTP 422 Unprocessable Entity
Paginated list endpoint:
#### GET /products
List products with pagination.
**Query Parameters:**
| Param | Type | Default | Description |
|-------|------|---------|-------------|
| page | integer | 1 | Page number |
| limit | integer | 20 | Items per page (max 100) |
| sort | string | createdAt | Sort field |
| order | string | desc | Sort order (asc/desc) |
**Response (200):** # HTTP 200 OK
{
"data": [Product],
"pagination": { "page": 1, "limit": 20, "total": 150, "totalPages": 8 }
}
Shared TypeScript interface:
interface ApiError {
code: string;
message: string;
details?: Record<string, string[]>;
}
Resources
${CLAUDE_SKILL_DIR}/references/writing-endpoints.md -- Endpoint definition template and key elements
${CLAUDE_SKILL_DIR}/references/typescript-interfaces.md -- Canonical type definitions and guidelines
${CLAUDE_SKILL_DIR}/references/pagination.md -- Pagination parameters and PaginatedResponse interface
${CLAUDE_SKILL_DIR}/references/best-practices.md -- Contract authoring rules (specificity, DRY, no implementation details)
Source: jeremylongshore/claude-code-plugins-plus-skills → skills/.curated/api-contract/SKILL.md
Also appears in: jeremylongshore/claude-code-plugins-plus-skills/plugins/community/sprint/skills/api-contract/SKILL.md
1---2name: api-contract3description: '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''. '4---5
6# API Contract
7
8## Overview
9
10API 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.
11
12## Prerequisites
13
14- Sprint directory initialized at `.claude/sprint/[N]/`
15- `specs.md` with defined feature scope and endpoint requirements
16- Familiarity with RESTful API conventions (HTTP methods, status codes, JSON schemas)
17- TypeScript knowledge for interface definitions (recommended)
18
19## Instructions
20
211. 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.
222. 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.
233. 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`.
244. 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.
255. 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).
266. Share the contract file path in SPAWN REQUEST blocks so both backend and frontend agents read the same interface definition.
27
28## Output
29
30- `api-contract.md` containing all endpoint definitions with typed request/response schemas
31- TypeScript interface declarations for `User`, `CreateUserRequest`, `LoginRequest`, `AuthResponse`, `ApiError`, and domain-specific types
32- Paginated response wrappers for list endpoints
33- Standardized error format across all endpoints
34
35## Error Handling
36
37| Error | Cause | Solution |
38|-------|-------|----------|
39| Backend and frontend schemas diverge | Contract updated without notifying both agents | Always reference a single `api-contract.md`; never duplicate endpoint definitions |
40| Missing error response codes | Contract only documents the happy path | Document all status codes: 400, 401, 403, 404, 409, 422 per endpoint |
41| Ambiguous field types | Using `string` without constraints | Specify format, length, and validation rules (e.g., "string, required, min 8 chars") |
42| Pagination inconsistency | List endpoints use different parameter names | Standardize on the `PaginatedResponse<T>` interface for all list endpoints |
43| Type mismatch between JSON and TypeScript | Dates serialized inconsistently | Use ISO 8601 datetime strings; document as `"createdAt": "ISO 8601 datetime"` |
44
45## Examples
46
47**Authentication endpoint contract:**
48
49```markdown
50#### POST /auth/register
51
52Create a new user account.
53
54**Request:**
55{
56 "email": "string (required, valid email)",
57 "password": "string (required, min 8 chars)",
58 "name": "string (optional)"
59}
60
61**Response (201):** # HTTP 201 Created
62{
63 "id": "uuid",
64 "email": "string",
65 "name": "string | null",
66 "createdAt": "ISO 8601 datetime" # 8601 = configured value
67}
68
69**Errors:**
70- 400: Invalid request body # HTTP 400 Bad Request
71- 409: Email already exists # HTTP 409 Conflict
72- 422: Validation failed # HTTP 422 Unprocessable Entity
73```
74
75**Paginated list endpoint:**
76
77```markdown
78#### GET /products
79
80List products with pagination.
81
82**Query Parameters:**
83| Param | Type | Default | Description |
84|-------|------|---------|-------------|
85| page | integer | 1 | Page number |
86| limit | integer | 20 | Items per page (max 100) |
87| sort | string | createdAt | Sort field |
88| order | string | desc | Sort order (asc/desc) |
89
90**Response (200):** # HTTP 200 OK
91{
92 "data": [Product],
93 "pagination": { "page": 1, "limit": 20, "total": 150, "totalPages": 8 }
94}
95```
96
97**Shared TypeScript interface:**
98
99```typescript
100interface ApiError {
101 code: string;
102 message: string;
103 details?: Record<string, string[]>;
104}
105```
106
107## Resources
108
109- `${CLAUDE_SKILL_DIR}/references/writing-endpoints.md` -- Endpoint definition template and key elements
110- `${CLAUDE_SKILL_DIR}/references/typescript-interfaces.md` -- Canonical type definitions and guidelines
111- `${CLAUDE_SKILL_DIR}/references/pagination.md` -- Pagination parameters and PaginatedResponse interface
112- `${CLAUDE_SKILL_DIR}/references/best-practices.md` -- Contract authoring rules (specificity, DRY, no implementation details)
113
114---
115
116**Source:** [`jeremylongshore/claude-code-plugins-plus-skills`](https://github.com/jeremylongshore/claude-code-plugins-plus-skills) → `skills/.curated/api-contract/SKILL.md`
117
118**Also appears in:** `jeremylongshore/claude-code-plugins-plus-skills/plugins/community/sprint/skills/api-contract/SKILL.md`