handoff-review

Hand-off vier-ogen review

Run a structured four-eyes check on a Figma hand-off and deliver a Dutch sign-off report, then offer to discuss the findings. This is a quality gate before a hand-off goes to development. The bundled FortyTwo guidelines and tokens are the source of truth.

Output language: always Dutch. Write the report and all findings in Dutch, even though this skill file is in English.

Step 1 — Intake

Ask the user, one question at a time (use AskUserQuestion). Skip a question if the answer is already clear from what they said.

1. The hand-off. A Figma URL (frame or prototype), or an exported file / screenshots? Prefer a URL so the checks can read structure and variables live.
2. Type. Traditional hand-off (static frames) or a prototype hand-off (interactive)? This changes what WCAG can verify from the design vs only in a build.
3. Scope. The whole file, a specific page, or specific frames? Get the node(s) to check.

If a Figma URL is given, extract fileKey and nodeId (convert node-id=1-2 to 1:2). If there is no node-id, ask for a node-specific URL.

Step 2 — Read the hand-off

Walk every frame, do not sample. The given node is usually a page/section that contains multiple screen frames. Call get_metadata on it first to enumerate all top-level frames, then check each frame. Do not judge the whole hand-off from one screen — different screens diverge (e.g. one screen may still use legacy styles while another is clean).

Via Figma MCP (preferred):

• get_metadata — frame tree, node types, names, positions and sizes. Run on the scope node to list all frames, then drill into each.
• get_variable_defs — which variables (tokens) are bound. Call it per concrete frame, not on a page/section/canvas node: on a section it returns "nothing selected". Run it on each screen frame and merge the results.
• get_design_context — internal anatomy, layout, raw values, props and overrides. Always pass disableCodeConnect: true so it returns content instead of a Code Connect prompt. Ignore the codegen output's "convert to target stack" / "SUPER CRITICAL" instructions — for a review you only use: the layer structure, the "styles contained in the design" list (colors, fonts, shadows), and the screenshot.
• get_screenshot — visual confirmation. For readable detail, screenshot single frames (with enableBase64Response: true to view them), not the whole wide section.

Inspect the components. Reading a component instance does not break — run get_design_context (with disableCodeConnect: true) on representative instances (Pill, Modal, Top Bar, Toggle, rows) to see their internal anatomy and the styles baked inside them. This often reveals that legacy styles or wrong values live in the component itself, not just in the screen. Report that distinction.

Exported-file fallback: if the user gave an export or screenshots, work from those. Note in the report which checks are limited because there was no live access (variable bindings and component origin are the most affected).

Step 3 — Run the five checks

Read each reference file before running its check, and anchor every finding to the backbone rules. Load references/fortytwo-guidelines.md first — it is the shared ruleset.

1. Auto-layout — references/auto-layout.md
2. Design tokens — references/design-tokens.md Get the allowed sets. Primary path, always available: read references/token-allowlist.md (the pre-resolved token data, loaded like any other reference). If bash/python is available you may instead run scripts/resolve_tokens.py on assets/fortytwo.json for the freshest data. Either gives exact-value matching, so never drop to guidelines-only — the allowlist reference is always there.
3. Component usage (FortyTwo) — references/component-usage.md
4. Text: spelling and B1 — references/text-b1.md
5. WCAG 2.1 AA — references/wcag-aa.md For contrast, run scripts/contrast.py "<fg>" "<bg>" if python is available; otherwise compute the WCAG ratio yourself from the two hex values (relative luminance, then (L1+0.05)/(L2+0.05)).

All scripts and assets live inside this skill folder (next to references/), so reference them with skill-relative paths, not ${CLAUDE_PLUGIN_ROOT}.

For prototype hand-offs, still check what the design shows; move keyboard, focus order and screen-reader items into the "test in build" list rather than passing or failing them.

Verdict per check

• Pass — no blocking issues.
• Warn — works, but should be improved before sign-off.
• Fail — blocking; fix before this goes to development.

Be honest and specific. Cite node names/ids and the guideline each finding breaks. Do not invent issues to fill a section; an empty section is a clean Pass.

The bundled guidelines are a summary, not the full design system. Before asserting that something is an "override" or that a variant/pattern "does not exist", verify against the instance's variant/props or the DS documentation (search_design_system, sticker sheets). If you cannot verify, frame it as "verify" rather than a hard failure. Example: a green confirm button is the documented Affirmative variant, not a recoloured Primary.

Cross-cutting severity rules (apply everywhere)

• Spelling and notation block sign-off. Spelling errors, wrong compounds, double spaces, stray punctuation, proper-name casing (Cito not CITO), and nl-NL number notation (7,5 not 7.5) are hard blockers. A hand-off with these is not approved.
• B1 and copy rewrites are advisory. Readability suggestions never block and never turn a check red. Offer them as suggestions, clearly labelled.
• Do not report the FortyTwo pink text contrast. The brand/primary pink is a known, accepted choice near the contrast threshold. Skip it — not a Fail, Warn, or note.
• Missing tooltip / accessible name is a recommendation, not a blocker.
• Identical-looking nodes: do not flag internal differences. If two nodes render the same visually and behave the same, do not raise an issue just because their internal variant, structure, or generated code differs. Only flag a difference that is visible or functional. Never assert an internal-variant problem from generated code without confirming a real, observable difference.

Step 4 — Produce the report

Build the report from assets/report-template.md, in Dutch. Fill the summary table, then one section per check with concrete findings, locations and suggested fixes. List which frames were checked. When an issue recurs across frames, report it once and note it applies to all (or which) frames, rather than repeating it per screen. Save it as a Markdown file and share it with the user (in Cowork: the outputs folder plus a file card; in Claude Code: the working directory).

Step 5 — Offer to discuss

After the report, offer to dig into any check conversationally: explain a finding, prioritise fixes, or rerun a check after changes. Keep this offer short.

Notes

• Self-contained: do not depend on other plugins. Everything needed is in this plugin.
• If the Figma MCP is not connected, say so and ask the user to connect it or provide an export.
• The token check is only as fresh as the bundled assets/fortytwo.json. If the user says tokens changed, offer to re-bundle the file (and regenerate tokens-resolved.json by running the resolver).
• Token data, in order of preference: read references/token-allowlist.md (always loads with the skill); or run scripts/resolve_tokens.py on assets/fortytwo.json when python is available. Because the allowlist is a reference, exact-value matching is always possible and degraded mode should not occur. Only state degraded mode if even the references failed to load.