●2.1.301 — Adds the vim % motion, LaTeX math rendering in the VS Code panel, and a retry-watchdog limit for usage-limit waits (10/15)●2.1.299 — Conversations over 200K tokens left idle about 54 minutes get compacted; MCP allow rules now match only the server they name●SONNET 4.5 — Retires on the Claude API on 11/30, 44 days left. Migrate to Sonnet 5.5●WINDOWS — Reports say hooks break silently only on Japanese-locale Windows; check the character encoding first●FAST MODE — Opus 5.5 fast mode is out of research preview and no longer needs the beta header (10/15)●NEW — I Put a Ten-Line Promise File at the To…●2.1.301 — Adds the vim % motion, LaTeX math rendering in the VS Code panel, and a retry-watchdog limit for usage-limit waits (10/15)●2.1.299 — Conversations over 200K tokens left idle about 54 minutes get compacted; MCP allow rules now match only the server they name●SONNET 4.5 — Retires on the Claude API on 11/30, 44 days left. Migrate to Sonnet 5.5●WINDOWS — Reports say hooks break silently only on Japanese-locale Windows; check the character encoding first●FAST MODE — Opus 5.5 fast mode is out of research preview and no longer needs the beta header (10/15)●NEW — I Put a Ten-Line Promise File at the To…
Designing Claude Design's Design System So It Isn't Throwaway
One pretty deck out of Claude Design isn't an asset if you rebuild the design system from scratch every time. Here is how to turn extraction into a repeatable operation, so anyone can spin up the same-quality deck from just a script — designed from the trenches of indie development and art.
When one polished deck comes out of Claude Design, most people stop there. But if you re-derive the design system from zero a few weeks later for the next deck, you're just repeating one-off outputs. After building apps solo since 2014 as an indie developer, the lesson I keep relearning is this: what pays off isn't a single artifact, it's the structure you leave behind that makes the second deck onward faster.
This article isn't about how to use Claude Design — it's about operating the extracted design system as a team asset. I covered the basics in handing Claude Design one old slide; here I deal with what comes after: reproducibility, scaling across people, and dividing the work with humans.
What "not throwaway" actually means
The test is simple: if a different person makes the same deck, does the brand reproduce at the same fidelity? If not, your design system isn't an asset yet. Claude Design builds a design system during onboarding by reading your codebase and design files, then reuses your colors, typography, and components automatically on later projects. The job of operations is to turn that "automatically on later projects" from tribal knowledge into steps anyone can follow.
What matters here is pushing the judgment out of one person's head and into measurements and steps anyone can follow. Writing down even an implicit rule like "titles join at most three words with a middle dot" means a different person produces headings with the same rhythm. Leaving something as a reusable template means verbalizing these small decisions one by one, so you never rediscover the same thing on every output.
What to make the system verbalize
To turn the extracted system into an asset, know what's been verbalized and add what's missing. At minimum, line up six elements:
Color (brand, surface, text, state colors)
Type scale (heading down to body)
Spacing scale (a system based on, say, a 4px unit)
Usage by context (pitch / recruiting / store image, and how each bends)
Write the just-extracted state into a single "spec core" so you can add diffs later. Something at this granularity:
# design-system.summary (the core a human finalizes after extraction)brand: primary: "#1E5BBF" # title bar / emphasis surface: "#F2F6FC" # tints / callouts text: "#1A2330"typography: base: "Yu Gothic Bold" scale: [32, 24, 20, 16, 14] # h1..captionspacing: unit: 4 scale: [4, 8, 12, 16, 24, 32, 48]tone: numbers: "show concrete values" emoji: "never"usage: recruiting: "wrap shared platform in a pale-blue callout" pitch: "one message per slide; push diagrams toward a single image"
The point is not to treat the extraction as sacred. The values the model reads always contain a few that drift from brand intent. I recommend keeping the order strict: a human finalizes it first, then you make it an asset.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦A priority order for what to feed Claude Design so design-system extraction is accurate
✦A composition-Markdown template that makes script-to-slide output reproducible
✦A rough-then-clean pipeline for complex diagrams, and rules that break key-person dependency
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
The same prompt — "build a design system" — produces very different accuracy depending on what you pass. In my experience the effective order is:
Finished real artifacts (existing slides, landing pages, logo)
Codebase / Figma files (tokens readable as structure)
Fragmentary specs like color and font choices
Description in words only
A single finished page tells the model far more than paragraphs of spec. That matches Anthropic's own framing — one finished landing page over a color-palette spec sheet. If your brand isn't settled yet, making one good reference page first is the shortcut; a found design or a generated image both work. Concentrating your first cost on one good real artifact is, in practice, the fastest path.
A composition-Markdown that keeps script-to-slide reproducible
The biggest lever for breaking key-person dependency was fixing the format in which scripts are handed over. Instead of pasting free text into chat, decide on a composition-Markdown template so anyone produces slides with the same skeleton. My template:
# Deck: <name> / Goal: <who should decide what>## Slide: title- message: <the one message this slide commits to>- visual: <type: bullets / comparison / matrix / single image>- body: - <point 1> - <point 2>- note: <which design-system usage to apply>
Sharing this gives decks the same effect the Findy engineering team got by turning AI-DLC into a skill so "anyone who runs it produces the same document skeleton." Forcing one message per slide alone cut the classic over-stuffing failure dramatically. With less rework after generation, total production time feels 2x to 3x faster.
A rough-then-clean pipeline for complex diagrams
The most accident-prone part in operation is complex diagrams. Instructing a role-by-phase matrix in words alone melts time into "tighten this, align that column." Fix a standard route:
Decide only the structure first (axes, what fills the cells)
Make a rough single image with image generation
Hand that rough to Claude Design: "clean this up with the same structure"
After cleanup, only tighten spacing and alignment with Edit
Redrawing a single image is cheaper in tokens, so rough by image generation / clean version in Claude Design is efficient on both time and cost. This is a workaround I found by failing several times on real decks, and it helps most exactly when words fail you. One pitfall: putting too much text in the rough drags the layout during cleanup — keep the rough structural and let the composition-Markdown carry the wording.
How to record diffs so the system keeps growing
An extracted design system is never finished the moment you finalize it. Values drift bit by bit every time a new use case appears. In my own workflow I keep a one-line change log inside design-system.summary. The trick is to record not just the value but why it changed — whether future-you can read that line in six months and recall the intent is what decides if the system stays a living asset.
# design-system.summary change log (excerpt)2026-05 added recruiting to usage (to unify hiring decks with a pale-blue callout)2026-06 added 48 to spacing.scale (vertical store images felt cramped under headings)2026-06 spelled out tone.rhythm as "middle dot, up to three words" (heading length varied per page)
Decide that the trigger for an update is "a new use case appeared," and you never agonize over when to review. Conversely, when you want to tweak a value but no new use case has shown up, that's usually a sign you're trying to push one deck's local quirk into the system — holding back here keeps the system clean. Stacking diffs as one-line additions rather than big overhauls is what makes it last.
Operating it so anyone hits the same quality
Summarized as a team workflow, the Before / After looks like this:
Aspect
Before (person-dependent)
After (asset)
Brand reproduction
rebuilt by hand, drifts per page
guaranteed by the design system
Script handoff
free text, uneven granularity
skeleton fixed by composition-Markdown
Complex diagrams
word round-trips, time melts
stable via rough-then-clean
Updates
fix every page by hand
just re-hand the script
Scaling
only a few can make it
newcomers use the same template
The pitfall is deciding the design system and the composition-Markdown once and leaving them. In real operation, adding one usage line each time a new context appears (a tall store image, say) causes fewer accidents than a big later overhaul. Growing it small keeps it usable longer.
Where to trust the AI, where humans hold the line
Finally, the division of labor. I believe humans must hold three things: final spacing tweaks, fact-checking, and the final brand judgment. Claude Design stands up skeleton and consistency astonishingly fast, but it doesn't guarantee "is this number current" or "may we commit to this phrasing as the brand." Hold those and you can delegate the rest boldly.
For me, the artwork itself uses no AI, while operational, outward-facing design — decks, icons, store images — leans on AI fully. That line is my own design for protecting creative time while running four sites and a Stripe membership. Start by deciding one composition-Markdown for your team. With one template in place, the speed of every deck after the first changes completely.
Share
Thank You for Reading
Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.