throughline

Show a plain-language summary of the current design system state — what's set up, what's not, and sensible next steps — read from design-system.json.

Author, refresh, or reconcile the usage documentation for one existing component — draft its canonical doc record from four sources, project it to Figma, the doc card, and code, and resolve any drift via a reviewable per-item choice.

Build a single new component end to end — in Figma, then sync any new tokens, then build its code component and stories — with a confirmation between each stage.

Start building your design system — the deterministic entry point. Runs environment setup first, before anything else.

Re-run the Figma-to-code token sync — extract current Figma variables, rebuild code outputs via Style Dictionary, and open a PR with the changes for review.

Reviews a completed unit of work for spec compliance and quality before it is combined or landed. Two modes — code-diff review (a git diff) and Figma-visual review (screenshot then analyze). Dispatched on the balanced tier, scaled to the diff's risk. Reports a verdict; does not fix.

Plans a build stage on the deep tier and emits a transcription-grade spec addressed in stable identifiers (component/page/token/style names, never nodeIds). Reads existing Figma state read-only to plan against it; it does not write. Dispatched concurrency-1 because it touches the single Figma bridge.

Transcribes code or generated output from a complete, transcription-grade spec and verifies its own build. Dispatched on the fast tier for mechanical, parallel-safe code-gen (per-adapter token output, per-component stories, SVGR transforms). Not for planning or design decisions — those belong to the dispatcher or the architect.

Runs an architect's Figma spec — resolves stable names to nodeIds at run time, builds into a named working frame, read-back-verifies structure (asserts a real COMPONENT_SET, not frames), and finalizes by build-verify-then-replace. Defaults to the balanced tier for a real component build; fast only for trivial mechanical ops. Concurrency-1, bridge-locked. Not for design decisions — those belong to the architect.

Build a foundational set of Figma components — buttons, inputs, cards, badges, chips, modals, and more — as properly structured components with variant matrices (types, sizes, states) and icon/component/content slots, bound to the design system's tokens and styles. Use this when the user wants to create components, build a component library, make buttons/inputs/cards/etc. in Figma, or set up the foundational UI kit. Also trigger after tokens and icons exist, when the user is ready to build actual UI components. Make sure to use this whenever someone wants real, variant-rich components in their Figma design system, not just tokens.

Take a single new component from Figma to fully-built-and-storied code, end to end — build it in Figma, sync any new tokens it introduced, then build its code component and stories. This is an orchestrator that sequences the component-builder, token-sync-layer, and storybook-chromatic-builder skills with a human confirmation between each stage. Use this when the user wants to add a new component to an existing design system, ship a component end-to-end, or run the full new-component flow. Also trigger on "/new-component" or when someone says they want one component built all the way through to code. Make sure to use this when the design system foundations already exist and the user wants to add one more component through the whole pipeline.

Measure a pre-existing design system before retrofitting it onto tokens — size the code-side color surface and inventory the existing Figma file with verified per-class reads, then compute how semantic the system already is so the retrofit is right-sized. This is a PROCESS skill and the brownfield front door. Use this when retrofitting a design system onto a mature codebase and an already-populated Figma file, when the user wants to audit an existing system, size a retrofit, count existing tokens/variables/bindings, or figure out how much work a migration is. Also trigger when figma-environment-setup detects a brownfield situation (existing repo or populated Figma file), before any building. Make sure to use this whenever someone is converging two mature, drifted artifacts rather than building greenfield.

Set up the local working folder and connect Claude to Figma so the design-system skills can read and write variables, styles, and components. This is a SETUP/PROCESS skill — it must run BEFORE brainstorming, not after it, because there is nothing to brainstorm until the environment exists. Invoke this skill immediately when the user wants to start, set up, or begin building a design system — phrases like 'let's setup my design system', 'let's get started', 'connect Figma', or 'build my design system' should all trigger this skill first, ahead of brainstorming. Also trigger when the user wants to fix a broken Figma connection, or mentions the Figma Console MCP, the desktop bridge plugin, or a Figma access token. It is the required foundation everything else depends on — always run it before any other design-system skill.

Build an icon system in Figma — a dedicated "Icons" page populated with the user's chosen icon library (Lucide, Material, or custom SVGs) as well-named, scalable components — using the fastest, most-automated mechanism per library (for Lucide, batch-fetching the curated subset's official SVGs from the source repo and componentizing them hands-off; for Material, the official community file or importer plugin) rather than hand-generating icons or making the user copy components by hand. Use this when the user wants to set up icons, add an icon library, import Lucide or Material icons, create icon components, or build an icon set in Figma. Also trigger when the user mentions iconography, an icon page, or needs icons for their components. Make sure to use this whenever someone needs a managed set of icon components in their Figma design system.