菜单
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'.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/diegosouzapw/awesome-omni-skill --skill api-handoff命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | api-handoff |
| description | 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'. |
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.
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
- 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.)