Prompts / handoff_spec
Design handoff spec for engineers Free
Produces a handoff document from a Figma frame or a design: behaviour, states, tokens, content rules, accessibility, edge cases and acceptance criteria.
Run it
- Claude Code:
/mcp__designers__handoff_spec - Claude Desktop and claude.ai: plus menu, Add from Designers, Design handoff spec for engineers
- Any app: Use the handoff_spec prompt from the Designers server on figma link or description of what is being handed off.
Arguments
| Name | Meaning |
|---|---|
design * | Figma link or description of what is being handed off |
stack | Framework and component library used |
* required
What your assistant is told to do
The full instructions, so you can see exactly what you are asking for:
Write the handoff an engineer wishes they got. The picture shows one state; the spec covers all of them.
Design: <design>
Stack: <stack>
Method:
1. If the input is a Figma link: parse it (figma.com/design/:fileKey/..., node-id=1-2 means nodeId "1:2"), call get_metadata to see the frames, get_screenshot for each frame you will judge, and get_design_context for layout, text and tokens. Read the picture before the code. If the Figma tools are not connected, say so and ask for screenshots or exported frames instead; do not guess at what is in the file. Use get_variable_defs to list the tokens in use (colour, type, spacing, radius) and flag any hard-coded values that should be tokens.
2. Write, for each frame or component: purpose in one line; anatomy and layout rules (what stretches, what is fixed, min and max widths, alignment); responsive behaviour at the breakpoints; every state (default, hover, focus, active, disabled, loading, error, empty, selected, long text, no data); and transitions with duration and easing.
3. Content rules: character limits, truncation and wrapping, localisation and right-to-left notes, real examples of the longest and shortest content.
4. Interaction and behaviour: what each control does, keyboard behaviour and order, validation timing, error placement, what is saved when.
5. Accessibility: roles and names for controls, focus management (modals, route changes), live announcements, target sizes, contrast results from check_contrast for each text and component pair, motion alternatives.
6. Analytics: events to fire at each moment (see prompt tracking_plan); call lint_tracking_plan on them.
7. Open questions and assumptions, labelled as such. Do not invent behaviour; ask.
8. Acceptance criteria as testable statements ("Pressing Escape closes the dialog and returns focus to the trigger").
Format as markdown with a heading per component, and keep each section skimmable. End with a list of the five things most likely to be built wrong.