菜单
Turn a design handoff into a task contract that can actually be checked — named source, resolved components, token names instead of raw values, and an explicit list of what stays unverifiable. Use when a Figma frame, mockup, or design spec is handed over for implementation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Convert a PRD, ticket, or feature request into a task contract that can fail — behaviour split from outcome, product nouns resolved to symbols that exist, unspecified cases surfaced as questions, and success metrics parked where a merge gate cannot wave them through. Use when product writing is handed over for implementation.
Enumerate what a change can reach and what enforces it — privileged operations and their callers, guards and the sites that apply them, and every module that reads a secret — before designing an auth, permission, or secrets change. Feeds the security review; produces a population and a gap list, never a verdict.
Read-only review of whether the tests in a finished change actually prove its behaviour — changed code no test reaches, a test exercising a different path than the one that changed, an assertion edited to match the new output, and a suite that ran nothing. Use after implementation, and whenever a change claims to be covered.
Gather who already depends on a service, handler, or state owner before changing it, and name the runtime gaps the codegraph cannot span. Use before designing a change to an API, queue consumer, background job, migration, or shared state; it feeds the architecture review rather than replacing it.
Read-only review of a finished UI change against the codegraph — a component nothing renders, a props contract changed without its callers, a reinvented component, or a raw value where the design system has a token. Use after implementing React or Vue work; triggers "review this UI change", "check the component", or a finished frontend diff.
Turn "I opened it and it looks fine" into recorded evidence — accessibility tree over screenshot, console and network errors as mechanical failures, viewport and colour-scheme checks as a checklist, and anything unchecked marked unchecked. Use after implementing a UI change in a client that can drive a browser.
| name | mastermind-design-intake |
| description | Turn a design handoff into a task contract that can actually be checked — named source, resolved components, token names instead of raw values, and an explicit list of what stays unverifiable. Use when a Figma frame, mockup, or design spec is handed over for implementation. |
| metadata | {"version":"0.1.0","authors":["mastermind"],"tags":["design","frontend","planning","figma"]} |
"Make it look like the design" cannot be verified by anything. Not by a test, not by the codegraph, not by a reviewer six weeks later. A design handoff has to be converted into names before it becomes acceptance criteria, or the contract is decorative.
This is a planning step. It produces the contract; it does not implement it.
Record the exact design source in the spec: file key and node id, or the frame URL. A spec that says "per the mockup" is unauditable — nobody can re-derive what was asked, and a design that moved on cannot be distinguished from an implementation that drifted.
If no stable reference exists, say so in the contract rather than pretending there is one.
A design tool that carries a code mapping states which repository components a
design already corresponds to. Read it, then confirm each mapped name against
the repository itself with mmcg_search — a mapping can name a component that
was since renamed or deleted.
A design element missing from the mapping does not mean the component is
missing from the codebase. Coverage is usually partial, and treating an
unmapped element as "new" is exactly how a fourth Button gets written. Fall
back to [[mastermind-component-research]] for anything unmapped, and record what
you searched.
The output of this step is a list of component names the implementation must use, each confirmed to exist.
Pull the design variables — colours, spacing, typography, radii — and carry
token names into the contract, never the resolved values. --color-danger
is checkable against the diff; #e5484d is a number that will drift the moment
the palette changes, and a reviewer cannot tell an intentional value from a
hardcoded one.
Where the design uses a value with no token behind it, that is a finding for the design system, not something to hardcode silently. Say which it is.
Each acceptance criterion should name a component, a token, a state, or an observable behaviour:
BaseButton with variant="primary""; "spacing comes
from --space-*"; "empty state renders when items is empty"; "the disabled
control is not focusable".Visual fidelity is real work and a real risk — it just is not a checkable criterion. Put it in an explicit section of the contract: what a human needs to look at, at which viewports, and against which frame. That keeps it visible instead of smuggling it into criteria that a mechanical gate will wave through.
The same applies to motion, easing, and anything whose correctness is a judgement call.
Use these headings so a reviewer can find each part, especially the last one:
### Source
<file key + node id, or frame URL>
### Components
- `<Name>` — confirmed present / unmapped, searched as `<queries>`
### Tokens
- `<--token-name>` — for `<what it covers>`
### Acceptance criteria
- <each one able to fail on the day the change lands>
### Not verifiable
- <what a human must look at, at which viewports, against which frame>
Not verifiable is never empty on a real design handoff. An intake that omits
it has smuggled a visual judgement into criteria a mechanical gate will pass.
It does not implement, and it does not promise the result will match. A contract built this way makes the structural half checkable — the right components, the right tokens, the right states. The visual half still needs eyes, and [[mastermind-browser-verification]] is where those observations get recorded as observations rather than as claims.