Generate design specs from code (not from a blank Figma)

The agent reinvented your Button. Different hex, different border radius, slightly wrong padding. You've seen some version of that mistake three times this week, and the root cause is the same every time: the agent had no contract to read, so it invented one.

Reverse-specs flips the process. Instead of writing a design system from a blank Figma, you read what already shipped, then write the contract agents need to stop guessing. The Clearly path is code to audit to DESIGN.md plus tokens and specs, then AI-ready governance (a Taste Profile agents cannot invent around). This page is that workflow. It is not a greenfield scaffold tutorial, and it is not an npm install guide.

On 17 Sep 2026, Google Search Console showed 2 impressions for "what's the workflow for generating design specs from code" (average position 11.5). Small number. We cite it because it's real, not because it looks like a market.

The workflow for generating design specs from code

This isn't a greenfield scaffold. You have a running React, Vue, Nuxt, or Next app. Docs are missing or stale. Agents keep inventing UI. The job is to read the frontend accurately, then write a machine-readable contract the next session can load.

1. Inventory your stack and CSS sources.

Start with package.json, then the places tokens actually live: tailwind.config or a theme file, tokens.css, CSS variables, and the component folders. You're mapping inputs before you extract anything. A Next app with Tailwind and one token file is straightforward. A Nuxt app with three legacy stylesheets, a component-library import, and an overrides file needs more care. Know what you're reading before you trust the output.

2. Extract primitives: colors, type, spacing, radii.

Prefer values that actually render, not values that exist in a file but get overridden three layers up. A color defined in tokens.css but shadowed by a Tailwind theme is not your real color. Live values usually win for the same reason they win in reconciliation: hundreds of screens already depend on what ships. The scan tools below handle most of the mechanical read. The gap is context. A tool can tell you --color-primary is #1A3CFF. It won't tell you that value only applies to the marketing surface and a different blue runs the product UI.

3. Classify existing components and patterns. Don't invent a new Button.

This is the step that matters most for agent governance. Map what already exists: Button, Input, Card, Modal, whatever the codebase actually ships. Document variants, states, and the props that control them. If the agent can see "Button has four variants and a disabled state," it is less likely to invent a fifth. If it can only see a color list, it will.

4. Write DESIGN.md plus a gaps list.

The DESIGN.md file carries the contract: primitives, component inventory, usage rules, agent constraints. The gaps list carries what the file cannot hold on its own: voice decisions, brand don'ts, context-specific rules, and anything that needs judgment rather than enumeration. Gaps aren't failures. They're the human-encoded layer that still needs encoding. One file alone is not a Taste Profile. That packaging argument is on DESIGN.md and Taste Profile.

5. Point agents at the contract, add an optional skill, and schedule re-runs.

Put the path in CLAUDE.md or a Cursor rule. Tell the agent to read DESIGN.md and the folder (tokens, specs) before generating UI, and not to invent tokens or component APIs that are not there. Do not paste the whole system into always-on context. An optional skill is how the procedure loads without stuffing CLAUDE.md. The hub for that is Claude Code design skills. Specs go stale. Pick a cadence and re-run when the UI drifts.

What extraction gets right vs what it invents

Scan tools are reliable on structure. They read color values, type scales, spacing steps, border radii, and component shapes from source. For a clean codebase with a single token source of truth, an extraction pass is a solid first draft of the primitives section and a component inventory you can correct.

They don't read intent. A tool can't tell you why you chose that type scale, what the Button's disabled state is supposed to communicate, or which interaction patterns are off-brand for your product. It can't write the don'ts. It won't package the voice decisions that separate your product from a reskin of someone else's component library.

That packaging is what we call a Taste Profile. On Clearly projects it is DESIGN.md plus tokens, component specs, voice, and optional SKILL.md, sitting inside the five-tier folder. It is Clearly's packaging language, not tasteprofile.io. Same two words. Different object. The longer argument is DESIGN.md and Taste Profile.

The practical split: extraction gives you the skeleton. Taste Profile packaging puts the judgment in.

Tools you can run today

SERP for this query is owned by tools and skills. They teach install, scan, write DESIGN.md. Use them when they fit. This page will not clone their READMEs.

Google Labs Stitch skill extract-design-md. Reads frontend source and writes a Stitch-compatible DESIGN.md with YAML tokens.

@creoit.com/design-md. Deterministic token extract plus agent prose for DESIGN.md.

design-spec (emirkrhan). Scan, then DESIGN.md, plus MCP design_context / design_lint.

Where Clearly still adds value after a scan: the scan gives you structure. What it will not produce is a prioritized gaps list, reconciled Figma-to-code conflicts, governance rules written for your actual agents, or a Taste Profile that encodes the judgment layer. That's the commercial fork, and only when the scan leaves gaps worth closing.

When reverse-specs is enough vs when to audit

If you have one repo, a clean Tailwind config, and an agent that mostly behaves, the open extract tools are probably enough. Run one, read the output, fill the gaps list yourself, point CLAUDE.md or a Cursor rule at the file and the folder.

The cases where extraction alone doesn't hold: your Figma and your code already disagree on at least a few values (see when the design system and the code disagree); you're running multiple repos with different token sources and no shared spec; or your agents are generating new components faster than any single pass can keep up with.

In those situations, an extraction pass names the easy part. The hard part is deciding which source is authoritative, which divergences matter, and what governance rules need to exist before you point another agent at the codebase. That's what a design system audit covers. We do not publish a standalone audit list price or a reverse-specs SKU. The method behind the code-side readout is Article 3. Read that first if you're deciding whether to DIY or bring in help. The offer page is the commercial front door.

For multi-repo products, or teams where agents are already doing real UI work, the audit often feeds a Taste Profile package. Live public pricing only: Standard $4,995/mo and Advanced $7,495/mo on a design partner retainer, and the AI design systems project at $8,000-$12,000. Confirm current numbers on clearly.design before you buy.

This isn't a hard sell for either path. If your codebase is clean and the tools above do the job, use them. Run the scan, write the gaps list, ship the contract. We'd rather you have accurate specs than a project you didn't need.

How this connects to Clearly's AI-ready stack

Generating specs from code is one door into a longer sequence. The map is the AI-ready design systems series. Adjacent pieces: DESIGN.md and Taste Profile for the contract vs the package, Article 3 for the read-only audit method, Article 6 for when tokens disagree, Claude Code design skills for the installable procedure, the design system audit offer, and the AI design systems project.

The pattern across all of them is the same. Agents work well when they have an accurate contract. The contract has to come from somewhere. For existing products, it comes from reading what shipped, not from inventing what should have been.

Book a call if the scan would only name the easy part, and the hard part is still sitting with a founder. Point agents at the contract either way. Just do not pretend the extract is the system.