菜单
Use this skill to prepare a complete handoff document for engineering. Triggers: 'prepare the handoff', 'write the handoff doc', 'I'm ready to hand off this feature', 'generate the spec for engineering', or when running as step 2 in the /design-handoff chain.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | design-handoff |
| description | Use this skill to prepare a complete handoff document for engineering. Triggers: 'prepare the handoff', 'write the handoff doc', 'I'm ready to hand off this feature', 'generate the spec for engineering', or when running as step 2 in the /design-handoff chain. |
You are a design handoff partner. Your job is to produce a complete, implementation-ready handoff document that engineering can act on without needing to ask the designer follow-up questions.
Read the working-language field from CLAUDE.md and deliver all prose in that language. Component names, prop names, code, and Vuetify references stay in English.
This skill runs as step 2 in the /design-handoff chain, after vuetify-constraint-check has confirmed all components are implementable.
When running standalone, ask the designer to confirm that Vuetify coverage has been verified before proceeding.
This skill reads the design directly from Figma. Text descriptions are not accepted as a substitute.
Before running any other step:
fileKey and nodeId from the URL:
fileKey: the segment after /design/ or /file/ in the URLnodeId: the node-id query parameter (replace %3A with :)If the MCP call fails (Figma not connected):
"Figma MCP is not connected. This skill requires direct Figma access. Open Claude Code → Settings → MCP Servers → add the Figma MCP → authorize. Once connected, share the frame link and we'll start." Stop completely. Do not continue with descriptions.
If no link is provided:
"Share the Figma frame link to proceed. This skill reads the design directly — text descriptions are not accepted." Stop. Do not ask follow-up questions based on descriptions.
Run all three:
get_design_context(fileKey, nodeId) — extracts full component and layout structure, variants, layer namesget_screenshot(fileKey, nodeId) — visual reference (attach to handoff document)get_variable_defs(fileKey) — extracts token values used in the frame for accurate token documentationFrom the MCP output, extract:
get_design_context)get_variable_defs)Before generating the handoff document, verify:
vuetify-constraint-check been run and passed? (No unresolved Vuetify gaps)design-policy-review been run and passed? (No unresolved policy blockers)If any prerequisite is unmet, flag it and do not proceed until the designer confirms it has been resolved.
Using the output from Step 0 MCP reads:
If design-policy-review or vuetify-constraint-check were run in this session, pull findings from those results.
For each UI element in the design:
For each interactive element:
## Design Handoff: [Feature Name]
### Overview
[One paragraph: what this feature does, the states designed, and any notable decisions]
### Prerequisites confirmed
- [ ] Vuetify constraint check: passed / ⚠️ [unresolved gap]
- [ ] Design policy review: passed / ⚠️ [unresolved issue]
- [ ] All required states: present / ⚠️ [missing state]
- [ ] PM wireframe approval: confirmed / ⚠️ [not confirmed]
### States
| State | Description | Trigger |
|---|---|---|
| Happy path | [description] | [trigger condition] |
| Empty state | [description] | [trigger condition] |
| Loading | [description] | [trigger condition] |
| Error (system) | [description] | [trigger condition] |
| Error (user input) | [description] | [trigger condition] |
### Component specification
#### [Screen / Section Name]
**[Component name]**
- Vuetify: `v-[component]`
- Props: `[prop]="[value]"`, `[prop]="[value]"`
- Slots: [slot usage if applicable]
- Theme tokens: `[token-name]` for [use case]
- Notes: [any non-obvious implementation detail]
[Repeat per component]
### Interaction behavior
| Element | Trigger | Result | Feedback shown |
|---|---|---|---|
| [element] | [event] | [state change] | [indicator / message] |
### Design decisions
[For each decision made during design:]
Decision: [short title]
Chose: [what was chosen]
Reason: [one sentence]
Trade-off: [what was given up or deferred]
### Open items
[Any items that could not be resolved before handoff — must be minimal]
🔴 [Item] — [what engineering needs to know / ask]
Use this skill when the PM is planning a new feature and needs to understand what technical dependencies exist before engineering starts. Triggers: 'we want to build this feature, what do we need to consider', 'engineering said it has dependencies but I don't know what', 'before we start I need to know which modules are affected', or any situation where a PM needs technical dependency analysis before committing to a feature.
Use this skill when the PM needs a complete feature spec to align the entire team: engineering, design, QA, and stakeholders. Triggers: 'write the spec for this feature', 'I need a document for the team meeting', 'the spec needs to be ready before the sprint starts', 'I want everyone on the same page about what we are building and why'. Do NOT use when the goal is purely engineering precision on error states and validation rules — use requirement-writer for that instead.
Use this skill when the PM describes a feature request, a problem, or an idea and needs to turn it into a clear, actionable DOD for the engineering team. Triggers: 'I want to build this feature', 'we have a problem that needs solving', 'management asked us to do this', 'how do I explain this to the team', 'what is the DOD for this task', or any situation where a vague idea needs to become a deliverable definition.
Use when a PM has raw Telegram message copy and needs to hand it to engineering as a ready-to-use Rich Message payload. Triggers: 'turn this into a Telegram rich message', 'format this for the bot', 'prepare this notification for Telegram', 'make a rich_message for this copy'. Converts plain copy into a valid InputRichMessage block (markdown or html) the technical team can pass to sendRich without edits.
Use when writing a task or issue for the team. Triggers: 'write a task', 'create an issue for this', 'log this as a task', or when any other skill explicitly hands off to this one. Use after problem-framing or feature-spec to convert the output into a ready-to-paste GitLab issue.
Use this skill to generate interactive HTML wireframes showing a feature in multiple states AND multiple interaction pattern variants. Triggers: 'show me what this looks like', 'generate a wireframe', 'I want to see all the states', 'show me different ways to implement this', 'make a visual prototype of the flow', 'what are the different UX options for this feature', or when running as step 4 in the /new-feature command chain.