/design-handoff
Use when a design is ready for engineering — produce an implementation-ready spec covering layout, tokens, states, responsive behavior, edge cases, motion, and accessibility.
$ npx -y skills add getcrew44/crew44 --skill design-handoff --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/design-handoff
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when a design is ready for engineering — produce an implementation-ready spec covering layout, tokens, states, responsive behavior, edge cases, motion, and accessibility.
SKILL.md
design-handoff.SKILL.mdname: design-handoff
description: Use when a design is ready for engineering — produce an implementation-ready spec covering layout, tokens, states, responsive behavior, edge cases, motion, and accessibility.
Design Handoff
Produce a spec that lets the Coding Agent build the design without guessing. If it isn't specified, they'll have to invent — and they'll invent inconsistently.
Principles
- **Tokens, not values.** Reference `--space-4` or `color-primary-600`, not `16px` or `#2563eb`. If a value isn't in the system, flag that as a token gap, not a one-off.
- **Show every state.** Default, hover, active, focus, disabled, loading, error, empty, success. A state you skip becomes a bug.
- **Explain the why.** "This collapses to a sheet on mobile because the action is one-handed" helps the engineer make sensible judgment calls when reality diverges from the spec.
- **Specify edges, not just the happy path.** Long text, no text, slow connection, partial data — pin the behavior.
Sections the spec must cover
1. **Overview.** What this screen or component does, who uses it, and the user state when they encounter it. 2. **Layout.** Grid, breakpoints, responsive behavior at each breakpoint. Where things move, hide, or change order. 3. **Tokens used.** Color, typography, spacing, radius, shadow — listed with their token names and where they apply. 4. **Components.** Each component named, with variants, props that matter for behavior, and any composition rules. 5. **States and interactions.** Per element, the full state list with the visual change and trigger. 6. **Responsive behavior.** What changes at each breakpoint. Not just "stacks on mobile" — what gets prioritized, what gets cut. 7. **Edge cases.** Long copy, empty data, zero results, max items, slow connection, error states. The expected behavior for each. 8. **Motion.** Per animated element: trigger, what moves, duration, easing. Honor `prefers-reduced-motion`. 9. **Accessibility.** Focus order, ARIA labels and roles, keyboard interactions, screen reader announcements, contrast confirmations.
Common spec gaps that cause rework
- Loading and error states for async content.
- What happens when content overflows (truncate? wrap? scroll?).
- Empty state for collections that start empty.
- Behavior under slow or failed network.
- Keyboard shortcuts and tab order through complex layouts.
- Animation choreography across linked elements.
Output
A single document with the sections above. Each section uses tables or short bullets, not prose paragraphs. Tokens and component names cited verbatim. Open questions called out at the bottom, tagged with who needs to answer (engineering, product, content).
Read more
name: design-handoff description: Use when a design is ready for engineering — produce an implementation-ready spec covering layout, tokens, states, responsive behavior, edge cases, motion, and accessibility.
Design Handoff
Produce a spec that lets the Coding Agent build the design without guessing. If it isn't specified, they'll have to invent — and they'll invent inconsistently.
Principles
- **Tokens, not values.** Reference `--space-4` or `color-primary-600`, not `16px` or `#2563eb`. If a value isn't in the system, flag that as a token gap, not a one-off.
- **Show every state.** Default, hover, active, focus, disabled, loading, error, empty, success. A state you skip becomes a bug.
- **Explain the why.** "This collapses to a sheet on mobile because the action is one-handed" helps the engineer make sensible judgment calls when reality diverges from the spec.
- **Specify edges, not just the happy path.** Long text, no text, slow connection, partial data — pin the behavior.
Sections the spec must cover
1. **Overview.** What this screen or component does, who uses it, and the user state when they encounter it. 2. **Layout.** Grid, breakpoints, responsive behavior at each breakpoint. Where things move, hide, or change order. 3. **Tokens used.** Color, typography, spacing, radius, shadow — listed with their token names and where they apply. 4. **Components.** Each component named, with variants, props that matter for behavior, and any composition rules. 5. **States and interactions.** Per element, the full state list with the visual change and trigger. 6. **Responsive behavior.** What changes at each breakpoint. Not just "stacks on mobile" — what gets prioritized, what gets cut. 7. **Edge cases.** Long copy, empty data, zero results, max items, slow connection, error states. The expected behavior for each. 8. **Motion.** Per animated element: trigger, what moves, duration, easing. Honor `prefers-reduced-motion`. 9. **Accessibility.** Focus order, ARIA labels and roles, keyboard interactions, screen reader announcements, contrast confirmations.
Common spec gaps that cause rework
- Loading and error states for async content.
- What happens when content overflows (truncate? wrap? scroll?).
- Empty state for collections that start empty.
- Behavior under slow or failed network.
- Keyboard shortcuts and tab order through complex layouts.
- Animation choreography across linked elements.
Output
A single document with the sections above. Each section uses tables or short bullets, not prose paragraphs. Tokens and component names cited verbatim. Open questions called out at the bottom, tagged with who needs to answer (engineering, product, content).
Orchestrate a crew of specialist AI agents in one local-first workspace. Each role on its best model, with memory and skills that compound. Free, MIT.
Repo: getcrew44/crew44
Other skills on crew44.
- /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Open skill - /finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Open skill - /receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Open skill - /requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Open skill - /systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Open skill

