Forge — Use Component

Prerequisite: forge.config.json exists at the repo root (run forge init once).

Advise on the existing library: pick the right component, give exact props, and hand back a working wiring snippet. Answer only from the brain so you never recommend a component or prop that doesn't exist.

The brain

Single source of truth: ${CLAUDE_PLUGIN_ROOT}/skills/_shared/DESIGN-SYSTEM.md. Always read these parts first, in order:

1. Foundations — tokens, theming (data-theme), source layout.
2. Conventions — house rules (className override hook, variant unions, sizes).
3. Accumulated guidance (in the brain) and ${CLAUDE_PLUGIN_ROOT}/skills/_shared/references/standing-guidance.md — these are corrections the team gave the engine; they override defaults.
4. The Component index table, then the matching ## <Name> section(s).

Workflow

1. Understand the need

Restate what the user is building in one line (e.g. "a destructive confirm dialog", "a data grid bound to an API"). If the ask is ambiguous between two components, ask one short question — otherwise proceed.

2. Match against the brain

• Scan the Component index for candidates by name, category, and import symbol.
• Open the candidate ## <Name> section(s). Read the Props table and Usage.
• Prefer the component whose documented purpose and props fit the need with the least glue. If two fit, name both and say when to pick each.

3. Answer

Give, concisely:

• Component + import — the exact symbol and import line from the section.
• Props to set — only the props relevant to the need, with types and defaults copied from the table (don't paraphrase types).
• Wiring snippet — a tsx block adapted from the section's Usage, filled in for the user's case (data source, handlers). Reference design tokens by their canonical names; don't inline raw hex/px.
• Caveats — if a prop's section is tagged _(inferred — confirm against source)_, surface that: the prop is read from docs/examples, not verified source, so it may differ. Never present inferred props as guaranteed.

4. When nothing fits

If no component matches, say so plainly. Do not invent one. Offer the create-component skill to scaffold it, or edit-component if an existing component is close but missing a prop.

Guardrails

• Answer only from the brain. If it isn't documented there, it doesn't exist for this skill — say so.
• Never invent props, defaults, or import paths. Copy them from the section.
• Standardize imports on the canonical bare package name from forge.config.json (the brain notes legacy/placeholder paths exist — don't reproduce them).
• Surface _(inferred)_ caveats every time they apply.