Create API handoff documentation for frontend developers. Use when backend work is complete and needs to be documented for frontend integration, or user says 'create handoff', 'document API', 'fronten
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add softaworks/agent-toolkit --skill backend-to-frontend-handoff-docs -a cursor -y
Create API handoff documentation for frontend developers. Use when backend work is complete and needs to be documented for frontend integration, or user says 'create handoff', 'document API', 'frontend handoff', or 'API documentation'.
Create API handoff documentation for frontend developers. Use when backend work is complete and needs to be documented for frontend integration, or user says 'create handoff', 'document API', 'frontend handoff', or 'API documentation'.
: Produce the handoff document only. No discussion, no explanation—just the markdown block saved to the handoff file.
You are a backend developer completing API work. Your task is to produce a structured handoff document that gives frontend developers (or their AI) full business and technical context to build integration/UI without needing to ask backend questions.
When to use: After completing backend API work—endpoints, DTOs, validation, business logic—run this mode to generate handoff documentation.
Simple API shortcut: If the API is straightforward (CRUD, no complex business logic, obvious validation), skip the full template—just provide the endpoint, method, and example request/response JSON. Frontend can infer the rest.
Produce a copy-paste-ready handoff document with all context a frontend AI needs to build UI/integration correctly and confidently.
.claude/docs/ai/<feature-name>/api-handoff.md. Increment the iteration suffix (-v2, -v3, …) if rerunning after feedback.Produce a single markdown block structured as follows. Keep it dense—no fluff, no repetition.
# API Handoff: [Feature Name]
## Business Context
[2-4 sentences: What problem does this solve? Who uses it? Why does it matter? Include any domain terms the frontend needs to understand.]
## Endpoints
### [METHOD] /path/to/endpoint
- **Purpose**: [1 line: what it does]
- **Auth**: [required role/permission, or "public"]
- **Request**:
```json
{
"field": "type — description, constraints"
}
{
"field": "type — description"
}
[Repeat for each endpoint]
[List key models/DTOs the frontend will receive or send. Include field types, nullability, enums, and business meaning.]
// Example shape for frontend typing
interface ExampleDto {
id: number;
status: 'pending' | 'approved' | 'rejected';
createdAt: string; // ISO 8601
}
[List any enums, status codes, or magic values the frontend needs to know. Include display labels if relevant.]
| Value | Meaning | Display Label |
|---|---|---|
pending | Awaiting review | Pending |
[Summarize key validation rules the frontend should mirror for UX—required fields, min/max, formats, conditional rules.]
[Key scenarios frontend should handle—happy path, errors, edge cases. Use as acceptance criteria or test cases.]
[Anything unresolved, pending PM decision, or needs frontend input. If none, omit section.]
---
## Rules
- **NO CHAT OUTPUT**—produce only the handoff markdown block, nothing else.
- Be precise: types, constraints, examples—not vague prose.
- Include real example payloads where helpful.
- Surface non-obvious behaviors—don't assume frontend will "just know."
- If backend made trade-offs or assumptions, document them.
- Keep it scannable: headers, tables, bullets, code blocks.
- No backend implementation details (no file paths, class names, internal services) unless directly relevant to integration.
- If something is incomplete or TBD, say so explicitly.
## After Generating
Write the final markdown into the handoff file only—do not echo it in chat. (If the platform requires confirmation, reference the file path instead of pasting contents.)