ThroughLine

Your agentic design team

Every skill you need to launch and manage a production-grade design system in hours — not months. Built for Claude Code, and installable into Cursor, Codex, or any AGENTS.md agent.

Whether you're starting from scratch or retrofitting an existing design system, ThroughLine puts you in the driver's seat — you make the high-level decisions while your agentic team powers through the production work. You stay in control of the what; it handles the how.

No code experience required.

Guides, examples and news live at radicool.studio/throughline.

What ThroughLine builds

In Figma

1. A robust primitive + semantic token system — color ramps, spacing, type scale, radius, and elevation, with light/dark and multi-brand modes.
2. Automatic generation of all text and effect styles — every type and shadow style, derived from your tokens.
3. A visual style sheet of every token and style for full team transparency — synced to your tokens on demand.
4. A full icon component system — Lucide, Material, or your own SVGs, imported as clean, scalable components.
5. A foundational component library — buttons, inputs, badges, cards, and more, built as proper variant matrices bound to your tokens.

In code

1. A pnpm + Turborepo monorepo on GitHub, scaffolded for you.
2. A sync adapter that syncs your Figma tokens and components to the code framework of your choice.
3. Storybook configured to house all synced components and their documentation.
4. CI via Chromatic for visual regression testing on every push.

Documentation

1. One record per component, rendered everywhere. Usage, variants, states, dos and don'ts, accessibility notes and the tokens it uses are written once, then rendered to the Figma description, a doc card on the canvas, Storybook, and an llms.txt digest your AI tools can read.
2. Docs that notice when they're stale. docs:check flags any copy rendered from an older version of its record, and a Storybook page someone edited by hand.

Checks

ThroughLine doesn't just build the system. It checks it, and the checks that guard a build stop it rather than print a warning.

1. Contrast, in every mode. Text-on-surface pairs are held to WCAG AA when tokens are created and again when they sync to code, so a theme that passes in light and fails in dark fails.
2. Focus you can see. On web frameworks, a component with no visible focus ring, or one below 3:1 against its surface, stops the Figma build.
3. Output that matches its source. tokens:validate-output checks generated CSS, Swift and Kotlin against the tokens they came from, because the stock transforms have been caught emitting wrong values that still compile.
4. Screens that use the system. In Figma, a detached component or a hardcoded color, gap, padding or radius where a token already has that value. In code (React and Angular), a raw color or size where a token exists, and a variant your component doesn't have.
5. Drift. /throughline:drift reports when Figma, the docs or the code have moved apart. It reports rather than blocks, apart from a broken screen or a hand-edited token file, which fail its CI script.

Use it every day

Once the system exists, these are the commands you'll live in. In Claude Code they're namespaced, so /throughline:drift. Other agents run the same skills by name.

| Command | What it does | |---|---| | /throughline:start | Set up from scratch, or pick up where you left off. | | /throughline:design-system-status | A plain-language picture of what's built and what's next. | | /throughline:sync-figma-tokens | Bring Figma's latest variables into code, as a pull request you review. | | /throughline:new-component | One new component, end to end: Figma, tokens, code and stories. | | /throughline:document-component | Write or refresh one component's docs, everywhere they appear. | | /throughline:check-figma | Check what's already in Figma against the system, without changing it. | | /throughline:compose-figma | Build a screen in Figma from your own components and tokens. | | /throughline:compose-code | Build the same kind of screen in code, as one React file. | | /throughline:gap-report | Everything your screens asked for that the system doesn't have, ranked. | | /throughline:drift | What moved since you built it, and the command that fixes each thing. |

Already have screens or components in Figma? /throughline:check-figma checks them against the system without touching the file: it flags a component someone detached, and a colour, gap, padding or radius that's hardcoded when a token already has that value. It also runs the state, focus-ring and focus-contrast checks over the components already in your library.

Need a new screen? /throughline:compose-figma builds it in Figma from your own components and tokens, every value bound. If the screen needs something your system doesn't have, it says so instead of drawing a lookalike, and it runs the same check before handing the screen over.

Want it in code instead? /throughline:compose-code writes the screen as one React file in your app, using only your components and your tokens. It checks the plan before writing a line, reports any component you don't have rather than building one, and gates the file before handing it over.

Every gap either composer reports gets kept. /throughline:gap-report ranks what your screens asked for and didn't get by how many screens asked, and calls out the ones where people keep reaching for something you already have. You decide what to build, what's already covered, and what to drop.

Things built from the system don't stay in step with it on their own. /throughline:drift tells you what moved. It flags a composed screen that uses a variant someone since removed, and one whose components changed underneath it. It flags a generated token file someone edited by hand, which the next sync would quietly overwrite. With Figma open, it also tells you which variable collections changed since your last sync, so you know the sync is overdue before anyone ships the old values. And it holds each component to its doc record: the states and options a Figma component has that its docs don't, and code built before the record's variants, states or tokens last changed. The code half is a plain script, drift:check, installed with the documentation scripts, so you can run it in CI.

Already have a design system? Retrofit it.

Most teams aren't starting from a blank file — they have a mature codebase with hundreds of hard-coded colors and a Figma file that's drifted from it over the years. ThroughLine treats that as a first-class path, not an afterthought, and it moves carefully: it never asserts what's in your files without reading them first, and it never deletes an old token until it's proven nothing still uses it.

1. Audit before anything changes. design-system-audit sizes both sides of your system — it greps your codebase to measure the real color surface and inventories your Figma file with verified, per-class reads — then tells you how big the migration actually is and how semantic your system already is.
2. A crosswalk that guarantees nothing shifts. token-crosswalk-builder maps every new token to its old Figma variable and old code value, then installs a tokens:validate gate that fails unless every resolved new value matches the old one (N/N). A zero-reference guard blocks removing an old token while any code still references it.
3. A gated, reversible migration. retrofit-planner walks the safe seven-phase sequence — audit → refine variables in place → rebind → sync → capture a visual baseline → retrofit the code → adopt existing docs → remove the old tokens — pausing for your confirmation between every phase, with an optional decision journal recording each call.

The payoff: your live product looks identical at every step, and you can prove it with a Chromatic baseline captured before the first change.

See a real end-to-end system built with it

| | | |---|---| | 🧩 Sample repo | The full monorepo — tokens, 14 components, Storybook, CI | | 📚 Live Storybook | Every component, all props, auto-generated docs | | 🎨 Public Figma file | The design source of truth it was generated from |

Everything above was created during a single working session and synced directly from Figma to a production-ready codebase.

Getting started

Requirements

| | | |---|---| | A supported agent | Required — Claude Code (native plugin), or Cursor, Codex, or any AGENTS.md-aware agent via npx @radicool/[email protected] init. | | Figma | Required, desktop app (the browser version causes connection errors). Professional plan or higher recommended — multi-mode variables (Light/Dark, brand themes) need it. | | Figma access token | Optional — only for the few Figma calls the Desktop Bridge can't make, like reading a published library. Without it, you work through the bridge alone. The setup skill walks you through it; your token stays yours and is never shared in chat. | | GitHub (or similar) | Optional — only when you're ready to graduate to a real remote repo with PRs and CI. |

What it runs on your machine

ThroughLine runs one local server. Nothing leaves your machine unless you choose it below.

• One local MCP server. Installing the plugin registers figma-console-mcp, pinned to version 1.40.8, which your agent starts on your computer with npx. It reaches the Figma desktop app through the Desktop Bridge plugin you run in Figma. That's how ThroughLine reads and writes your file. For the Figma calls the bridge can't make, it uses a Figma access token if you give it one. Claude Code asks for the token as a plugin setting and keeps it in your system's secure credential store. It's optional. The Cursor, Codex and generic installs read it from FIGMA_ACCESS_TOKEN instead.
• Files in your repo. The skills write design-system files where you point them: token sources, the Style Dictionary build, components, stories, design-system.json, and the proof records in design-system/proof/. The helper scripts they install read and write local files and make no network calls.
• GitHub, if you choose it. repository-builder offers to create a GitHub repository and push to it, and shows you the command and waits for your yes before it runs. Once your repo is on GitHub, each token sync lands there as a pull request for you to review. Stay at a local folder or local git and nothing goes to GitHub.
• Chromatic, if you choose it. Setting up Chromatic adds a CI workflow that uploads your Storybook to your Chromatic project, using a CHROMATIC_PROJECT_TOKEN you place yourself. Skip that step and nothing goes to Chromatic.

Install

ThroughLine is authored as a Claude Code plugin and generated into adapters for other agents. Pick your tool:

Claude Code

Install from this repo's plugin marketplace:

/plugin marketplace add jrpease/throughline
/plugin install throughline@throughline-marketplace

Then start with:

/throughline:start

This is the reliable entry point — it runs environment setup first, ahead of anything else. (You can also just say "let's set up my design system", but if you have other plugins installed that grab "let's build…" style phrases, the slash command guarantees ThroughLine takes the wheel.)

Update anytime with /plugin marketplace update throughline-marketplace.

Cursor, Codex, or a generic AGENTS.md agent

Run the installer in your project — it stamps in the skills, the reference docs, the scripts, and the Figma MCP config for your tool:

npx @radicool/[email protected] init --target=cursor    # → .cursor/rules + .cursor/mcp.json
npx @radicool/[email protected] init --target=codex      # → prompts/ + AGENTS.md index + codex-mcp.toml
npx @radicool/[email protected] init --target=generic    # → skills/ + AGENTS.md index

It's safe to re-run (it merges AGENTS.md and .cursor/mcp.json non-destructively) and stages everything the skills read into .throughline/. Then open the figma-environment-setup skill/rule/prompt for your tool to begin. For Codex, add the printed codex-mcp.toml block to your Codex config to enable Figma access.

Architecture

ThroughLine is more than a pile of skills — it's a small system designed to stay consistent across dozens of generation steps. Four layers work together:

🛠 Twelve skills — the steps. Each owns one stage of the journey, from connecting Figma to retrofitting an existing system to standing up CI. They're sequenced, and each knows its prerequisites.

📐 The reference docs — the constitution. Shared standards every skill obeys: Figma component rules (auto-layout-on-everything, slot contracts, naming-as-contract, a required post-build audit), the brainstorm-before-build protocol, the sync-adapter specs, the manifest schema, coding-level adaptivity, the publishing flow, and the brownfield-retrofit discipline (read-before-assert, the safe migration sequence, the crosswalk contract). This is why two different runs produce the same structure — the rules live in one place, not scattered per skill.

🧭 An orchestration layer — the memory. A design-system.json manifest in your project records exactly what's set up, with a versioned schema and immutability rules. Every skill reads it, tells you what it's about to do, and offers to run anything missing first. Run /design-system-status anytime for a plain-language picture of where you stand.

🔌 An adapter layer — the bridge. A Style Dictionary pipeline that translates your Figma variables into whatever code framework you target — and re-translates on every change. When something does slip, /throughline:drift says what and where.

The skills

| Skill | What it does | |---|---| | figma-environment-setup | Create your working folder, connect Claude to Figma, scan what already exists. Start here. | | design-system-audit | Measure an existing system before retrofitting — size the code-side color surface and inventory the Figma file with verified reads. The brownfield front door. | | token-builder | A two-tier (primitive + semantic) token system as Figma variables, plus text/effect styles. Generative, descriptive, or import-your-own. | | token-sheet-builder | A beautiful, on-brand Foundations page visualizing every token, live-bound to the variables. | | icon-system-builder | An Icons page with your chosen library (Lucide, Material, or custom) as clean components — the cheap, fast way. | | component-builder | Your foundational components (button, input, card, modal…) with full variant matrices, slots, and token bindings. | | repository-builder | Graduate your folder into a pnpm + Turborepo monorepo — folder → local git → GitHub, one gentle step at a time. | | token-sync-layer | Sync Figma variables to framework-specific code via Style Dictionary, landed as a reviewable PR. Installs /sync-figma-tokens. | | token-crosswalk-builder | Map new tokens to their old Figma variables and old code values, and install the tokens:validate gate that proves no value changed during a retrofit. | | storybook-chromatic-builder | Storybook, component stories, Chromatic visual testing, and Code Connect (where your Figma plan supports it). | | component-pipeline | Add one new component end to end: Figma → tokens → code + stories. Installs /new-component. | | retrofit-planner | Orchestrate a full retrofit through the safe, gated seven-phase sequence — with a human checkpoint at every phase. |

The nitty gritty

For the technically curious — how the machine actually runs.

The sync layer. Figma variables are extracted to DTCG-format JSON (the W3C design-tokens standard), run through Style Dictionary, and shaped by a framework adapter into the exact output your stack expects — shadcn CSS variables, a Tailwind theme, MUI theme objects, Swift/Kotlin constants, or plain CSS. Because the code is generated from the extract, design and code can't drift: you never hand-edit outputs, you change Figma and re-run. The sync lands as a pull request, so every design change is reviewable, diffable, and CI-checked before it merges.

The monorepo. A pnpm + Turborepo workspace: packages/ holds the generated tokens and the component library; apps/ is where you build the actual product against your own design system. ThroughLine grows it in stages — plain folder → local git → GitHub remote with PRs and CI — introducing each concept only when its payoff is concrete, so you're never dropped into the deep end.

The manifest. design-system.json is the single source of truth for state: a versioned schema, canonical per-skill flags, an immutable record of how your project began (greenfield vs. existing repo), and a snapshot of tooling detected at setup. Skills read it to know what's done and what's safe to do next — which is how the system stays coherent across many sessions.

Modes, within Figma's limits. Light/Dark lives on the semantic collections; brand variants live on the primitive palette. Splitting the two axes across two collections keeps each one under Figma's 4-modes-per-collection cap on the Professional plan while still resolving correctly (bg/default → {gray/50} → the active brand's gray).

Model routing. ThroughLine routes work by cognition, not guesswork — the expensive thinking on the best model, the mechanical doing on a cheap one. Inside a skill, the deciding — a token architecture, a variant matrix, a slot contract — is planned once on the strongest tier, while the long mechanical part — placing Figma nodes, transcribing component code, running SVGR — runs on a cheap tier and self-verifies. You get the best model where it matters and a cheap one where it doesn't, without micromanaging it. The recommended mapping is Haiku → Sonnet → Opus for the fast < balanced < deep tiers, but nothing is hardcoded — the ladder resolves against whatever models your install actually has, and on hosts without subagents skills degrade cleanly to a single model. You can still steer the session yourself (/model opus for the heaviest authoring, back to /model sonnet after); nothing forces an expensive model on you.

Who it's for

1. Solo designers who spend a lot of time building and managing design systems.
2. Agencies consistently spinning up new design systems for clients.
3. Design teams constantly fighting to keep their Figma and code systems in sync.
4. Non-designer vibe coders who want a stronger design-system backbone on their projects.
5. Engineers looking to bridge their code and design ecosystems.

Why I built it

I'm a designer who got tired of the handoff. Design systems live in two places that never quite agree — the Figma file and the codebase — and keeping them in sync is a full-time job nobody wants. ThroughLine is the tool I wished existed: it lets a designer drive the whole pipeline, learn the engineering one concept at a time, and end up with a real, shippable system instead of a pile of redlines. If you're a designer who's becoming a developer, this was built for you.

Show it off

Built your own system with ThroughLine? Add the badge so others can find it:

[![Built with ThroughLine](https://img.shields.io/badge/Built%20with-ThroughLine-6366f1)](https://github.com/jrpease/throughline)

Contributing

ThroughLine is open source and contributions are welcome. Found a bug or have an idea? Open an issue. Want to improve a skill or reference doc? PRs are encouraged — the skills are Markdown, so they're approachable to edit.

A couple of ground rules:

• Figma is the source of truth. Generated code files are build artifacts — never hand-edited; change things in Figma and re-sync.
• Secrets stay yours. Tokens and keys are never sent through chat or committed to code.
• The plugin validates itself. Every PR runs CI (.github/workflows/ci.yml) — the full test suite plus zero-dependency structural validators that check plugin.json, the marketplace manifest, and every skill/command's frontmatter. Run them locally with node --test and node ci/validate-plugin.mjs / node ci/validate-skills.mjs.

Roadmap

Future improvements and planned capabilities. Have a request? Open an issue — the roadmap is shaped by what people actually build.

• More framework adapters — broaden the Style Dictionary output targets beyond the current set.
• Deeper Code Connect coverage — richer Figma-to-code mappings as more plans support it.
• Expanded component starters — a larger foundational kit out of the box.
• Reading component code — /throughline:drift now checks Figma components against their doc records and knows when code was built against an older record. What it can't do yet is read the code itself, or compare the properties the record doesn't describe (text, toggles, icon swaps).
• More accessibility checks — contrast and focus rings are checked today (see Checks), and the code gate fails an icon-only button with no accessible name and a status badge that relies on color alone. Keyboard behaviour and wider ARIA patterns aren't checked yet, and the checks haven't caught a bug in the wild so far: the one real app they've run on gave them little to check.
• Token fan-out to more platforms — the DTCG token source is platform-neutral, and web targets are in daily use. Every target is validated per build, not assumed: tokens:validate-output checks generated output against its source, native Swift and Kotlin as well as web CSS, because the stock transforms have been measured emitting wrong-but-compiling values. iOS/Swift is a curated adapter whose Style Dictionary configuration ships as tested code, and Android/Kotlin uses the same configuration through the Tier 2 protocol. JavaScript theme output (MUI, a Tailwind v3 config) isn't checked yet.
• Native component code generation — producing a SwiftUI view or a Compose composable the way Storybook components are produced for React. This does not exist yet; it is a separate, larger effort than token fan-out, and the two were previously described as one roadmap item.

Versioning follows Semantic Versioning. The current version lives in .claude-plugin/plugin.json; every release is recorded in CHANGELOG.md.

License

MIT © Jordan Pease