Use this when a design is approved and engineers need clear specifications to build it. Produces annotated handoff documentation covering behavior specs, responsive rules, interaction notes, accessibility requirements, and acceptance criteria mapping. Bridges the gap between "looks good in Figma" and "built correctly in code."

Related skills: Run /design-review before handoff to catch issues. Use /component-spec for reusable component documentation. Feed acceptance criteria into /story-write.

Process

Step 1: Gather inputs

Ask the user to provide:

1. The approved design -- Figma link, screenshots, or prototype URL
2. The story or feature spec -- acceptance criteria, PRD section, or feature description
3. Design system -- component library or style guide the team uses (if any)
4. Target platforms -- web (responsive?), iOS, Android, or all
5. Breakpoints -- the team's responsive breakpoint definitions (or use defaults: 320, 768, 1024, 1440)

Step 2: Component inventory

List every distinct component visible in the design:

## Component Inventory -- {{feature name}}

| Component | Existing in DS? | Variant | Notes |
|-----------|----------------|---------|-------|
| (e.g., DataTable) | Yes / No / Modified | (e.g., sortable, paginated) | (customizations needed) |

Flag components that don't exist in the design system -- these need new component specs or custom implementation.

Step 3: Behavior specifications

For each interactive element, document what happens:

## Behavior Specs

### {{Component or interaction name}}

**Trigger:** (What the user does -- click, hover, focus, swipe, type)
**Action:** (What the system does in response)
**Feedback:** (What the user sees/hears -- animation, state change, message, sound)
**Duration:** (Animation timing if applicable -- e.g., 200ms ease-out)
**Reversibility:** (Can the user undo this? How?)

#### State transitions
| From state | User action | To state | Visual change |
|------------|------------|----------|---------------|
| Default | Hover | Hover | (describe change) |
| Default | Focus | Focused | (describe focus ring) |
| Default | Click | Active/Loading | (describe transition) |
| Loading | Complete | Success | (describe confirmation) |
| Loading | Failure | Error | (describe error display) |

Step 4: Responsive behavior

## Responsive Specifications

| Breakpoint | Layout change | Components affected | Notes |
|------------|--------------|--------------------|----- |
| < 320px | (minimum supported -- what breaks?) | | |
| 320-767px (mobile) | (layout description) | (components that change) | (stack, hide, reorder) |
| 768-1023px (tablet) | (layout description) | (components that change) | |
| 1024-1439px (desktop) | (layout description) | (components that change) | |
| 1440px+ (wide) | (layout description -- max-width or fluid?) | | |

Step 5: Accessibility notes

## Accessibility Requirements

| Element | Requirement | Implementation |
|---------|------------|----------------|
| (interactive element) | Keyboard operable | Tab order: (specify), Enter/Space to activate |
| (dynamic content) | Screen reader announcement | aria-live="polite" for (state change) |
| (form field) | Error association | aria-describedby linking to error message |
| (modal/dialog) | Focus management | Trap focus, return to trigger on close |
| (images) | Alt text | (specific alt text or aria-hidden if decorative) |

Step 6: Content and copy specifications

## Copy Specs

| Element | Copy | Character limit | Dynamic? | Truncation rule |
|---------|------|----------------|----------|-----------------|
| (heading) | (exact text) | (limit) | Yes/No | (ellipsis, wrap, tooltip) |
| (CTA) | (exact text) | (limit) | No | N/A |
| (error message) | (exact text) | (limit) | Yes -- (variable) | (rule) |

Step 7: Compile and present

Combine all sections into a single handoff document. Ask the user:

• Are there interactions I missed?
• Does the team need more detail on any component?
• Should I generate stories from these specs using /story-write?
• Any platform-specific considerations I should add?

Output location

Present the handoff document as formatted text in the conversation. For team use, export to Notion, Confluence, or attach to the relevant stories in the project tracker.