agentleFS
jgamaraalvjgamaraalv/delivery-loop/.claude/skills/backend-to-frontend-handoff-docs/SKILL.md

backend-to-frontend-handoff-docs

Skill0 starsChanged 4 months agoMITView on GitHub

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'.

4 other projects use a version of this, 4 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 5 are common, 0 are distinctive, and 0 are very specific to this project.

  • 5

    Common

    Most of the 4 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    If backend made trade-offs or assumptions, document them.

    line 34
  2. Common:

    Keep it scannable: headers, tables, bullets, code blocks.

    line 35
  3. Common:

    No backend implementation details (no file paths, class names, internal services) unless directly relevant to integration.

    line 36
  4. Common:

    If something is incomplete or TBD, say so explicitly.

    line 37
  5. Common:

    Write the final markdown into the handoff file only—do not echo it in chat.

    line 40

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

API Handoff Mode

No Chat Output: 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.

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.

Goal

Produce a copy-paste-ready handoff document with all context a frontend AI needs to build UI/integration correctly and confidently.

Inputs

  • Completed API code (endpoints, controllers, services, DTOs, validation).
  • Related business context from the task/user story.
  • Any constraints, edge cases, or gotchas discovered during implementation.

Workflow

  1. Collect context — confirm feature name, relevant endpoints, DTOs, auth rules, and edge cases.
  2. Create/update handoff file — write the document to .claude/docs/ai/<feature-name>/api-handoff.md. Increment the iteration suffix (-v2, -v3, …) if rerunning after feedback.
  3. Fill the template — read references/handoff-template.md and fill every section with concrete data. Omit subsections only when truly not applicable (note why).
  4. Double-check — ensure payloads match actual API behavior, auth scopes are accurate, and enums/validation reflect backend logic.

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.)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.