- Home
- The Thinking Wire
- Four Skills That Bind Claude Code to Your Design System
Four Skills That Bind Claude Code to Your Design System
For five posts we have argued that design systems are governance infrastructure for AI. The argument moved this week. Two practitioners shipped the operational details.
Sen Lin, currently Senior Product Designer at Worldline and previously Lead of Futures Innovation at Thoughtworks, published four Claude Code Skills on GitHub. They force the agent to read the token map, confirm the brief, search the component registry, and bind every visual property to a variable before writing to Figma. Open source. Pick them up today.
In the same week, Romina Kavcic published the systemic frame: components as contracts, semantic tokens carrying useFor and avoidFor metadata, quality gates from axe-core, Chromatic, and stylelint already running at Microsoft, Shopify, and IBM.
The harness model we wrote about for engineering now ships for design. The governance question is identical: who approves what, when.
The Four Skills, Named
Sen Lin’s repository at github.com/senlindesign/claude2figma is not a framework. It is four Markdown files that any team can drop into a Claude Code project today.
Preflight. Before the agent draws anything, it loads a baseline. The token map (color, spacing, typography, radius). The component registry. The naming conventions. If any of these are missing, the agent refuses to proceed. Lin’s framing is exact: “what I built is not a harness. A harness is an architectural concern. It lives at the system level. What I built is closer to a workflow enforcement layer.” Preflight is the entry gate to that layer.
Reference Interpreter. The agent reads the Design Brief and rewrites it back in its own words before executing. This is the same pattern senior engineers use in pull requests: restate the requirement, surface ambiguity, get confirmation. For design work the failure mode is identical. An agent that interprets “make it cleaner” without confirmation will produce six redesigns of the same screen. Reference Interpreter forces the contract before the work.
Component Rules. Search the library before invention. If a button exists, use the button. If a card variant covers the case, use the variant. The Skill explicitly prohibits generation of components that already have registry entries. This is the rule Figma’s MCP integration enables structurally; Lin’s Skill makes it enforceable in Claude Code regardless of whether you are using MCP.
Style Binding. Every visual property must trace back to a variable. Color references the token. Spacing references the scale. Typography references the type system. Lin adds a post-write QA pass: the Skill reopens the generated artifact and verifies that no raw hex codes, magic numbers, or one-off font sizes slipped through. This is the closing constraint. Without it, the first three Skills can still produce output that drifts.
These four are not suggestions. They are sequential. Preflight establishes the boundary. Reference Interpreter establishes the goal. Component Rules constrains the move. Style Binding verifies the result. Skip any one and the chain breaks.
What Kavcic Adds: The Contract Layer
Lin’s piece tells you what to enforce. Kavcic’s piece tells you what to enforce against.
Her central claim is that prompts do not scale. Structure does. A design system that consists of components, examples, and prose explanations gives the agent ambient context and hopes for the best. A design system that consists of components-as-contracts gives the agent enforceable rules.
A component contract, in her formulation, has five fields. Intent (what the component is for). Variants (what shapes it takes). Rules (when to use which variant). Accessibility (what it must satisfy). Anti-patterns (what it must never do). The agent reads the contract and either complies or fails the check. There is no interpretation required.
Tokens get the same treatment. Kavcic argues against generic semantic tokens like color-primary and for behaviorally-tagged tokens like:
color-action-primary:
value: "#1A73E8"
useFor: ["main CTA", "primary navigation"]
avoidFor: ["decoration", "background"]
The metadata is the constraint. An agent reading useFor and avoidFor knows where the token belongs and where it does not. The token is no longer a value. It is a value plus a usage policy.
She cites the quality gates already running in production. Microsoft’s Fluent system uses adaptive interfaces with explicit rules for AI-generated content. Shopify Polaris ships semantic tokens with behavioral metadata. IBM Carbon runs stylelint validation in CI to catch unauthorized variable use. Spotify runs background coding agents inside contract-bound systems. Gartner projects 40% of enterprise apps will embed task-specific agents by end of 2026. The infrastructure is not theoretical.
Why The Pairing Matters
Lin gives you the enforcement layer. Kavcic gives you the contracts the layer enforces against. Either piece alone is incomplete. Together they describe a shipping pattern.
Read it this way. The four Skills are a workflow that runs inside Claude Code. The contracts are the artifacts the workflow consults. Preflight loads the token map and component registry. Reference Interpreter parses the Design Brief into structured intent. Component Rules queries the contract for the matching component. Style Binding verifies the output against the token metadata.
This is the same operational shape as governed engineering. The harness loads tests, lints, and CI before the agent writes code. Skills load tokens, contracts, and validation before the agent writes design. The discipline is identical. The vocabulary travels.
What is new here is the closing of an operational distance we have flagged in previous pieces. We argued that design tools were bypassing the constraint layer. That design systems needed to evolve from documentation to infrastructure. That substrate adapts to the agent era. Those arguments were directional. Lin and Kavcic make them concrete. The four Skills exist. The contract pattern exists. Companies are running both.
The Honest Limits
Three caveats before adoption.
Lin’s Skills are open source and recent. They have been published, not battle-tested across hundreds of design teams. The patterns are sound. The edge cases are not yet documented. Treat the four Skills as a starting harness, not a finished one.
Kavcic’s company examples are real but selective. Shopify, IBM, and Microsoft have the scale and discipline to run contract-bound design systems. A 12-person product team will not deploy stylelint pipelines and Chromatic visual regression overnight. The pattern direction is correct; the maturity ladder runs steeper for smaller teams.
The governance question Lin’s framing surfaces remains open. He distinguishes a harness (“an architectural concern, at the system level”) from his workflow enforcement layer. The distinction is useful. It also means the four Skills do not answer the bigger question: who decides what the contracts say, how they change, when they break. That is a governance role, not a tooling role. The harness model from engineering carries the same gap, and we have not yet solved it there either.
Do This Now
If you maintain a design system and your team uses Claude Code, three concrete steps this week.
One: clone github.com/senlindesign/claude2figma. Read all four Skill files. They are short. The total time investment is under an hour.
Two: audit your tokens for behavioral metadata. If your tokens are values without useFor and avoidFor fields, you cannot enforce against them. Start with the five tokens that get misused most often. Add the metadata. Document the anti-patterns.
Three: pick one component, write its contract using Kavcic’s five fields, and test whether the agent produces compliant output when constrained by the contract versus when prompted in prose. The difference is the entire argument for structure over prompts.
Design systems are governance infrastructure. This week the infrastructure got shipping documentation.
This analysis synthesizes How to Make Claude Code Follow Your Design System in Figma (Sen Lin, UX Collective, May 2026) and Agentic Design System: From Chatbot to Orchestration (Romina Kavcic, The Design System Guide, May 2026).
Victorino Group helps design and engineering teams operationalize governed autonomy across the design canvas. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation