pre-handoff-review

Checks that a design is complete enough to hand to engineering by running the specialist skills that own each part of a specification - states and edge cases, responsive and localisation behaviour, accessibility annotations, final copy, design-token and component compliance, motion specification, platform conventions and analytics instrumentation - and produces a readiness table of blockers, gaps and the artifact list engineering will receive. Use before a design review with engineers, when a designer says "this is ready to build", or when engineering asks what is missing from a spec. Triggers on design handoff, handoff checklist, ready for development, design spec review, dev handoff, spec completeness, missing states, edge cases, redlines, design to engineering.

Pre-handoff review

Answers one question: can an engineer build this without guessing? It coordinates the skills that own each part of a specification and owns only the completeness checklist, the readiness table and the artifact list.

This is not a quality review of the design itself; that is product-design-review. A design can be beautiful and unbuildable, or plain and complete.

Inputs

The design: files, prototype or exported screens, with any written spec.
The target: platform, frameworks, the design system in use, supported locales, and whether analytics is expected.
The engineering team's questions, if any were raised already.

Workflow

1. Inventory what exists

List every screen and component in the design, and for each the states that are specified. Note the sources of truth the team uses (tokens file, component library, copy deck, DESIGN.md).

2. Run the completeness checks

Each check names the owning skill; read that skill completely before applying it and take its rules, not a paraphrase.

Check	Owner	Passes when
States	this skill	Every component specifies empty, loading, error, partial, overflow (long text, many items), disabled and success states, or explicitly inherits them from the system
Responsive behaviour	`better-layout`	Breakpoints and what collapses are specified; nothing depends on a single viewport
Localisation readiness	`localization-design`	Text expansion, RTL mirroring and locale formats are accounted for in the layout
Accessibility annotations	`a11y-planner`	Focus order, names, roles, keyboard behaviour and announcements are specified before code
Accessibility of the spec	`better-accessibility`	Contrast and target sizes verified where the design fixes them
Final copy	`better-writing`	Every label, error and empty state has final text; no lorem ipsum, no "TBD"
Tokens and components	`design-system-governance`	Values map to tokens; new components are justified and named
Extracted system, if none is written	`extract-design-md`	A DESIGN.md exists or is generated from the codebase for engineers to reference
Motion	`motion-system` and `animation-vocabulary`	Durations, easings and triggers are named tokens or explicit values
Platform	`platform-conventions`	Native patterns are followed or deviations are deliberate and stated
Analytics	`instrumentation-plan`	Events and metrics are specified for the flow, with consent handling
Decision record	this skill	Major choices and rejected alternatives are written down with the reason

Confirm each named skill is installed; mark a missing one Not checked and say so. Never apply a missing skill's rules from memory.

3. Classify gaps

Blocker: engineering cannot proceed or would guess something users will notice (missing error state, unspecified focus order, placeholder copy on a primary action, values with no token in a tokenised system).
Gap: proceed possible with a documented assumption that the designer confirms later.
Note: nice to have before launch.

4. Report

Design: <name>   Target: <platform, system, locales>
| Check | Owner skill | Status (Pass / Gap / Blocker / Not checked) | Detail | Action and owner |
Artifacts to hand over: <list: screens, states matrix, copy deck, token map, a11y annotations, motion spec, analytics plan, decision record>
Readiness: Ready | Ready with assumptions | Not ready
Skills used: <ids>

Not ready when any blocker remains. Assumptions travel with the handoff as a list the designer owns.

Before you finish

Mistake	Fix
Reviewing visual quality	Send to `product-design-review`; check completeness here
Passing a state matrix that says "same as default"	Require the actual behaviour for overflow, error and empty
Accepting values instead of tokens in a tokenised system	Map or justify each raw value
Leaving analytics for after launch	`instrumentation-plan` is part of the spec
Reporting gaps without owners	Every action names the person who closes it

On this page