Turn a rough component idea into a variant and props spec a Figma builder can execute without guessing

You are writing a component brief for one specific reusable component that is about to be built in Figma — either by me directly, by a junior designer I'll hand this to, or by Figma's AI companion inside a file. The brief needs to be precise enough that the builder never has to guess a variant, a prop name, or a state that I didn't specify.

COMPONENT
Primary action button used inside the checkout flow's order summary card

WHERE IT'S USED
Sits at the bottom of the order summary card on desktop and mobile web; the only place in the product where a button sits directly above a price total

KNOWN VARIANTS NEEDED
state: default, hover, pressed, disabled, loading; size: default, compact

EXISTING DESIGN TOKENS TO REUSE
color/action/primary, color/action/primary-disabled, radius/md, spacing/8, spacing/12, type/label-md

HARD CONSTRAINTS
Must stay a single auto-layout frame so it can be swapped into three different card widths without manual resizing, and the loading state must not change the button's height

BRIEF RULES
Open with a one-sentence definition of the component's job — what it is FOR, not what it looks like, because a builder who understands the job can make a better call on an edge case I didn't think to specify. Build the variant matrix as an explicit grid: every property (like state, size, emphasis) crossed against every value it can take, and mark which combinations are actually valid — a component with 3 properties at 3 values each has 27 theoretical combinations, but maybe only 14 are real; naming the invalid ones prevents someone from dutifully building all 27. For every variant property, name it exactly as it should appear in the Figma variant panel (e.g. "state", not "Component State") since inconsistent naming here is what makes instance-swapping painful later. For every prop that should be exposed (text content, icon slot, boolean toggles), state the type and, for booleans, what showing true actually changes in the layout — not just that a toggle exists. Specify auto-layout behavior explicitly: which direction it resizes, what has a fixed size versus hug versus fill, and what the minimum viable size is before content starts clipping. Reuse existing tokens by exact name wherever color/action/primary, color/action/primary-disabled, radius/md, spacing/8, spacing/12, type/label-md covers the case, and only invent a new token when nothing in that list fits — name the gap explicitly rather than silently picking a new color or spacing value that could drift from the system. Call out interaction states that are easy to forget — disabled, loading, error, empty — and say whether each one is in scope for this pass or explicitly deferred, so a missing state reads as a decision, not an oversight.

WHAT NOT TO DO
Do not describe visual style in prose ("should look clean and modern") — every visual instruction must be a specific token, value, or exact match to an existing component. Do not invent variants beyond state: default, hover, pressed, disabled, loading; size: default, compact unless a stated hard constraint makes one clearly necessary — flag any variant you added and why, rather than quietly expanding scope.

OUTPUT FORMAT
1. One-sentence component job statement.
2. Variant matrix as a table: property, values, valid combinations, invalid combinations explicitly marked out.
3. Exposed props table: name, type, default, what changes when set.
4. Auto-layout spec: resize direction, fixed/hug/fill per axis, minimum size.
5. Token reuse list plus any new tokens proposed, each with a one-line justification.
6. States in scope for this pass and states explicitly deferred, with a one-line reason for each deferral.