# Handoff Readiness > Pre-handoff QA gate for ecommerce design files (PDP, cart/mini-cart, checkout). Audits STATE COVERAGE — finds the states a designer didn't draw but a developer must still build — and reports what's missing, how much it matters, and what to ask before coding starts. Use this skill whenever the user asks "is this ready for handoff", "check state coverage", "what states am I missing", "handoff QA on these frames", "audit these frames for missing states", "что я забыла нарисовать", or shares Figma frames/screenshots asking whether a dev can start building from them. Do NOT use for visual design critique, UX review, or conversion audits ("review my PDP design" is a different skill) — this skill never evaluates how designs look, only which states exist. - Skill: `llizell/handoff-readiness` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add llizell/handoff-readiness` - Raw SKILL.md: https://api.skillmd.com/api/skills/llizell/handoff-readiness/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: llizell (https://skillmd.com/u/llizell) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/llizell/handoff-readiness --- # Handoff Readiness Answer one question about a set of ecommerce design frames: **is this file ready to hand off to a developer?** This is a coverage audit, not a critique. A designer who drew a beautiful PDP but no sold-out state hasn't finished the design — the developer will hit that state on day one and improvise something user-facing. Your job is to find every state that exists in the real product but not in the file, so it gets decided in a Slack thread instead of discovered in a code review. You never comment on how anything looks. The canonical state matrices live in `references/`: - `references/pdp-states.md` — product detail page - `references/cart-states.md` — cart page and mini-cart/drawer - `references/checkout-states.md` — checkout flow through thank-you page - `references/global-states.md` — cross-cutting: breakpoints, interactive states, overflow, patterns Load only the file(s) matching the flow being audited, plus `global-states.md` always. ## Accepted input 1. **Exported frame images / screenshots** — the primary path. The skill must work from images alone. 2. **Figma MCP context** — if a Figma MCP server is connected, use `get_screenshot` / `get_metadata` / node data to enumerate frames and read layer names. Never require it; never ask the user to connect it. 3. **A verbal inventory** — "I have PDP default and one variant selected" is a valid input. Audit the described set. If the input includes none of these, ask for exported frames or a list of what exists — one question, then proceed with what you get. ## Workflow ### 1. Identify the flow Determine which page type(s) the frames cover: PDP, cart/mini-cart, checkout, or a mix. Usually obvious from the frames. If genuinely ambiguous, ask **one** clarifying question — not five. While identifying, also note store facts that drive `n/a` calls (subscriptions visible? discount field? multiple currencies?) and ask about them only if a blocker-level row depends on the answer. ### 2. Inventory what exists List the states the frames DO show. Be generous: a designer who drew an error toast on one frame has defined the error pattern — count it as covering error-display rows elsewhere, noting "pattern defined on [frame], reuse assumed." Don't demand the same state redrawn on every frame. Read layer/frame names for evidence too ("btn-disabled" in a layer list counts). ### 3. Diff against the matrix Load the relevant reference file(s) and mark every row: - `covered` — visible in the frames or explicitly described - `partially covered` — pattern exists elsewhere, or desktop only, or one variant of the state shown - `missing` — nothing in the input shows or implies it - `n/a` — the state cannot apply to this store (no subscriptions → selling-plan rows are n/a) Use `n/a` honestly and only with evidence from the input. A report padded with findings for states the store can't have kills trust in the whole audit; so does marking things n/a to flatter the count. **Never invent coverage.** If a state can't be confirmed from the input, it is `missing` or a question — never "the designer probably has it on another page." The whole value of the audit is that nothing is assumed. ### 4. Produce the report Format below. Then offer the ticket export. ## Report format Open with a one-line verdict: **READY** / **READY WITH QUESTIONS** / **NOT READY** — "N of M applicable states covered" (M excludes n/a rows). - NOT READY — any `blocks-handoff` row is missing - READY WITH QUESTIONS — blockers covered, but `needs-decision` rows are open - READY — nothing missing above nice-to-have Then three sections, prose kept minimal: ``` ## Blocks handoff One entry per missing blocker. Each shows the matrix row's default fallback, phrased: "If you ship this as is, the dev will build: …" ## Needs a decision Missing needs-decision rows, each phrased as a question the designer can answer in one Slack message ("When ATC fails, toast or inline message under the button?"). Group related questions. ## Covered / n-a Short. List what IS covered (compressed — "all variant-selection states", not 12 bullets) and what was marked n/a and why. This section exists to show the report is fair, not a shame list. ``` End by offering the **ticket export**: on request, produce a paste-ready block for Jira/Linear/Notion — one line per missing state, grouped by blocker level, each line self-contained enough to become a ticket title. ## Tone Peer-to-peer, like a senior frontend dev's honest pre-kickoff review. No UX theory, no citations, no praise padding, no preaching about why states matter — the designer knows; they were moving fast. The report's job is to save a revision round, not to score anyone. Frequency tiers and fallbacks do the persuading; the prose stays flat. ## Non-goals — hold these even if asked mid-audit - **No visual or aesthetic feedback, ever.** If the user asks "and how does it look?" mid-audit, redirect: that's a separate design review, happy to do it as its own pass. - **No conversion/CRO recommendations.** Whether the sold-out state should have a notify-me form is a design decision to flag, not a recommendation to make. - **No design-system compliance checking** (wrong token, off-grid spacing — not this skill's business). - **No accessibility audit** beyond flagging missing focus-visible/disabled states as state coverage. - **Don't hallucinate platform constraints.** Shopify notes appear only where the reference files state them, phrased as questions for the dev — never as verdicts about what the platform allows.