Handoff Spec
Turn approved UI designs into developer-ready specs with spacing tokens, states, assets, edge cases, and accessibility notes so implementation matches intent.
Overview
Handoff Spec is an agent skill most often used in Build (also Validate, Grow) that produces complete design-to-dev specifications with measurements, behaviors, assets, and edge cases.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill handoff-specWhat is this skill?
- Visual specs: spacing, design tokens, typography, radius, shadows, breakpoints
- Interaction specs: hover, focus, disabled, transitions, gestures, keyboard order
- Content rules: limits, truncation, empty/loading/error copy, localization and RTL
- Asset delivery checklist: SVG icons, image variants, fonts, illustrations
- Edge cases and a11y: min/max content, per-breakpoint behavior, ARIA and screen reader notes
- 6 handoff sections (visual, interaction, content, assets, edge cases, implementation notes)
Adoption & trust: 571 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Developers guess at spacing, states, and breakpoints because the design file never spelled out behaviors and edge cases.
Who is it for?
Indie products with designer-founders or contractors handing UI to themselves or a part-time dev on web or mobile surfaces.
Skip if: Pure API or CLI backends with no visual product surface to specify.
When should I use this skill?
A design is ready for implementation and you need measurements, behaviors, assets, and edge cases documented for developers.
What do I get? / Deliverables
You get a single handoff document developers can implement against, cutting UI bugs and design-review loops before Ship.
- Developer handoff document
- Token-referenced visual and interaction matrix
- Asset and edge-case checklist
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Handoff is where design becomes buildable UI; the canonical shelf is Build because the primary artifact feeds frontend implementation. Frontend is where pixel behavior, responsive rules, and component states land in code—even when design owned the earlier mocks.
Where it fits
Finalize prototype screens with tokenized spacing before committing to frontend sprint work.
Generate a handoff for a checkout flow including error, loading, and disabled button states.
Archive implementation notes and asset naming conventions alongside the spec for future contributors.
Update character limits and truncation rules when marketing copy changes in key UI modules.
How it compares
Use as a structured handoff template instead of dumping Figma links without tokenized specs or state matrices.
Common Questions / FAQ
Who is handoff-spec for?
Solo builders and tiny teams moving from design mocks to frontend implementation who need explicit specs, not interpretive coding.
When should I use handoff-spec?
After Validate when locking a prototype for Build, when starting a new screen or component in frontend work, or when revisiting UI during Grow content or layout updates.
Is handoff-spec safe to install?
It generates documentation only; review the Security Audits panel on this page and avoid pasting secrets into handoff content.
SKILL.md
READMESKILL.md - Handoff Spec
# 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