Skip to content
Development
Skill

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

From plugin
crew44
35862 skills4 agents
Install
$ npx -y skills add getcrew44/crew44 --skill design-handoff --agent claude-code

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

Read more
Ships withcrew44

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.

Get the whole plugin