Design-task intake

Purpose

A terse design prompt ("the dropdown hover doesn't work") is usually answerable but not complete — the missing pieces surface mid-task and cost time. This runs a ~60-second completeness check first: resolve what the repo already tells you, surface the few genuine gaps, confirm which assets (if any) are actually needed — so the build/fix is fast and right the first time.

The gate — don't add friction to a good prompt

Interview only for gaps that change what you do or how fast. If you can already state the scope, the expected vs. actual (bug) or the target state + acceptance (change), and you know where the spec/assets are, skip the questions, restate the task in one line, and proceed. Interrogating for things the repo answers — or for low-stakes details — is the anti-goal. Most prompts pass the gate; the interview is the exception, not the toll booth.

When the prompt was pasted as a piece of work, the tier comes before this whole skill runs. The first reply is a Tier: line (per ~/.claude/CLAUDE.md) naming the model, reasoning label and mechanism for the build or review being asked for, plus at most one line saying what job you read in the paste, and nothing else — no repo reading, no intake questions, no code. Then wait for the maintainer's go (g) and run this skill from step 1. The intake questions come after the go, not beside the tier, because step 1's whole point is self-answering from the repo first and that reading is the spend the wait protects.

One gate, once: for design tasks this skill is the intake step — don't stack another start-of-task gate on top of it (the general form of that rule now lives in ~/.claude/CLAUDE.md, "Reach for a skill before improvising"). Run this, then hand off.

1. Self-answer from the repo first (never ask what you can check)

• Is the accepted preview attached to the task or already downloaded? Identify the exact file and state before asking for it again. Design bundles are temporary working inputs and do not live under docs/.
• Is this a regression? git log / blame the component or area; a recent change often is the cause.
• Which screen / route / component owns it? (navigation/ia.ts, navigation/webRoutes.ts, the screen file, theme/primitives.tsx.)
• Screen-local fix, or shared token/primitive? A fix that can only be made by editing a shared token (theme/tokens.ts), a theme helper, or theme/primitives.tsx changes every surface that consumes it — its blast radius is app-wide even when the task named one screen. If shared: name the other affected surfaces up front, add at least one to the manual-QA set, and plan a PR tradeoff callout. (Flagship: the #194 contrast fix darkened shared faint/muted tokens site-wide, not just the signed-out home.)
• What's the current behavior? Run it (just up) or read the code. For a bug, a repro beats a mockup.

2. Classify, then check the right list for genuine gaps

Bug ("X doesn't work"):

• Scope: which surfaces, and desktop / mobile-web / both?
• Does the sibling interaction also fail? Hover and click/focus both dead on an element that clearly renders ⇒ pointer interception / stacking, not styling. Single most useful tell (it's what the nav-dropdown bug, #171, turned out to be).
• Expected vs. actual, and a repro path (which URL / state).
• Environment: localhost, Vercel preview, or prod — and is it new or a regression (since when)?

Build / change (from a mockup):

• Which state(s) change — and is the spec/screenshot for that state available? Ask for the specific state, not the whole bundle.
• Copy / naming / grounded-answers invariants touched? (docs/design/ui-copy-guide.md, .claude/rules/grounded-answers.md.)
• Any data/backend dependency, and the interim behavior if it isn't built yet?
• Acceptance criteria (what "done" looks like) and any held/deferred items.

3. Ask only the gaps — batched, with defaults

Put the genuine unknowns to the user in one AskUserQuestion call (≤ 4 questions, each with a recommended default so it's one click). Never ask what step 1 already answered. If nothing material is missing, say "prompt is complete — proceeding" and move on.

4. Restate, then hand off

State the sharpened task in one line — scope · deliverable · acceptance · assets needed — then continue with design-build (build/change) or systematic-debugging (bug).

Anti-patterns

Interrogating for repo-discoverable facts · asking low-value questions · gating an already-complete prompt behind an interview · requesting the whole design bundle when one state's screenshot/spec section suffices · skipping straight to code on a genuinely ambiguous prompt.

References

.claude/skills/design-build/SKILL.md (the build workflow this feeds) · .claude/skills/design-review/SKILL.md (the pre-build mockup evaluation that precedes intake) · .claude/rules/workflow.md rule 14 (surface real ambiguity; don't gate routine work) · docs/product-onboarding/site-navigation-guide.md. Origin: retro on the nav-dropdown hover fix (#171).