Rule shapes

During extraction, every rule the agent finds falls into one of seven shapes. The shape decides where the rule lands in the produced skill, and whether it lands at all.

Why shapes matter

An extracted rule needs three things: a destination file, a section heading, and a citation. The shape decides all three. Misclassifying a shape produces a real defect: a copy rule slipped into a DS skill, a peer-graph link to a file that does not exist, or a rule deferred to a sibling skill that never lands.

Shapes also determine what stays out. Two of the seven shapes do not produce extracted rules in the DS skill: one routes elsewhere, one defers until later.

The seven shapes at a glance

The shapes in detail

Shape 1 · Component-selection extract

Looks like: A peer-component table or paragraph that says "use X when Y, use Z when W". Cross-references at least one sibling component.

Find in: Component docs (.mdx, README.md), Storybook story descriptions, cross-linked "See also" sections.

Extract as: A paragraph under ### When to use in the component's reference file. Wrap each sibling component name in a peer-component link: [Combobox](./combobox.md).

Watch for: Fuzzy thresholds ("under ~10 items", "past 3 options"). The threshold is the rule. Preserve verbatim. Do not round.

Shape 2 · Prop-usage extract

Looks like: A rule about how to use a specific prop, or which prop to prefer over another. "Use loading over a manual spinner swap." "Use type='submit', not a custom typeName."

Find in: TypeScript types (*.d.ts, prop interfaces), JSDoc on the prop, prop tables in docs, runtime warnings inside the implementation.

Extract as: A bullet under ### Key props or ### Behavior. Every prop, value, and literal API token in backticks. Cite source as file:line inline.

Shape 3 · Naming or casing or copy route out

Looks like: "Title Case the label." "Placeholder is action-oriented." "Modal title is never a question." "Button copy starts with a verb."

Find in: Copy guidelines, placeholder examples, component best-practices blocks with naming rules embedded.

Do not extract: Mention it in the discovery summary as a candidate for a sibling copy skill. Never write it into the DS skill. The scope guardrail is the single most-violated rule in dry-runs because the source genuinely contains the rule and the model wants to extract it.

Shape 4 · Accessibility extract

Looks like: ARIA attribute requirements, keyboard interaction contracts, screen-reader announcement behaviour, focus-management rules.

Find in: aria-* attributes in the implementation, a11y test files (*.a11y.test.tsx), axe-cited rules in docs, focus traps in modal or dialog primitives.

Extract as: A bullet under ### Accessibility. Cite the runtime behaviour (focus trap, ARIA role) and the trap it prevents.

Watch for: Rules lifted from prose docs without a code-level reference. Pair with a [VERIFY] marker.

Shape 5 · Default-state extract

Looks like: The initial render state when no props are passed. "Default focus target on a Modal." "Default Cancel button position on a destructive dialog." "Default loading={false} semantics."

Find in: Implementation defaults (useState(initial), default-prop destructuring), Storybook default stories, prop-table default columns.

Extract as: A bullet under ### Behavior. State the default and the consequence of overriding it incorrectly.

Shape 6 · Cross-skill back-reference defer

Looks like: A rule that depends on a sibling skill. "Use the icon skill's primitive, not raw SVG." "Error toast copy lives in the copy skill, mirror it here."

Find in: Prose docs that cross-link other skills, bidirectional rule mirrors (toast rules mirrored across a DS skill and a copy skill).

Defer for v1: No sibling skills exist in the workshop scaffold yet. Mark the rule [DEFER] during extraction so it is visible to the user but does not pollute the routing table. Pick up when the second skill in the cluster lands.

Shape 7 · Anti-substitution extract

Looks like: Prose that names a peer component as the wrong choice for the current surface, often hedged with "experimental", "deprecated", "preview", or "reserved for". Trigger phrases: "use X, not Y", "do not reach for Y", "Y is reserved for...", "only reach for Y when...".

Find in: Component annotation files (.docs.tsx, *.docs.mdx, best-practices blocks), README "When NOT to use" sections, ADRs that record a deliberate avoidance.

Extract as: A bullet under ### Best Practices or ### When to use in the in-scope component's reference file. The rule belongs to the component the agent will reach for, not the one it should avoid. Keep the avoided peer's name in backticks even when the peer is outside the proposing set (no link target exists). Preserve the DS author's hedge ("experimental", "reserved for") verbatim.

Watch for: Misclassification as Shape 1 produces a broken link to a non-existent peer file. Misclassification as Shape 2 loses the peer name entirely.

The two shapes that do not produce extracted rules

Signals that help tell shapes apart

What to take away

1. Seven shapes total. Five extract, one routes out, one defers.
2. Shape 3 (copy) is the most common scope violation. Recognise it. Route it out. Do not extract.
3. Shape 6 (cross-skill back-reference) is deferred for v1. The marker is [DEFER], not [VERIFY].
4. Shape 1 vs Shape 7 is the most important difference to get right. Shape 1 lands a link to a sibling file. Shape 7 lands a plain-backtick warning naming an out-of-scope peer.
5. Fuzzy thresholds in Shape 1 are the rule. Preserve them verbatim.

---

Primary source: .claude/skills/extract-ds-skill/references/component-extraction.md (full shape definitions, find-in patterns, extraction targets, signals that tell shapes apart). SKILL.md's summary covers six shapes; the seventh (Anti-substitution) lives only in the reference file.