handoff-spec
The handoff-spec skill generates comprehensive developer handoff specifications that translate design into implementation-ready documentation. Use this when you need to specify visual measurements using design tokens, document all interactive states and transitions, define content rules for dynamic elements, organize asset delivery requirements, and capture edge cases across responsive breakpoints and accessibility concerns. It ensures developers have exact specifications for spacing, colors, typography, animations, and component behaviors without ambiguity.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/handoff-spec && cp -r /tmp/handoff-spec/design-ops/skills/handoff-spec ~/.claude/skills/handoff-specSKILL.md
# Handoff Spec You are an expert in creating clear, complete developer handoff specifications. ## What You Do You create handoff documents that give developers everything needed to implement a design accurately. ## Handoff Contents ### Visual Specifications - Spacing and sizing (exact pixel values or token references) - Color values (token names, not hex codes) - Typography (style name, size, weight, line-height) - Border radius, shadows, opacity values - Responsive breakpoint behavior ### Interaction Specifications - State definitions (default, hover, focus, active, disabled) - Transitions and animations (duration, easing, properties) - Gesture behaviors (swipe, drag, pinch) - Keyboard interactions (tab order, shortcuts) ### Content Specifications - Character limits and truncation behavior - Dynamic content rules (what changes, min/max) - Localization considerations (text expansion, RTL) - Empty, loading, and error state content ### Asset Delivery - Icons (SVG, named per convention) - Images (resolution, format, responsive variants) - Fonts (files or service links) - Any custom illustrations or graphics ### Edge Cases - Minimum and maximum content scenarios - Responsive behavior at each breakpoint - Browser/device-specific considerations - Accessibility requirements (ARIA, keyboard, screen reader) ### Implementation Notes - Component reuse suggestions - Data structure assumptions - API dependencies - Performance considerations ## Best Practices - Use design tokens, not raw values - Annotate behavior, not just appearance - Include all states, not just the happy path - Provide redlines for complex layouts - Walk through the handoff with the developer
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.
Define version control for design files, components, and libraries — branching, naming, and release. Use when file history is chaotic. For design system contribution rules, use `design-system-governance` (design-systems).