design-system-code
把设计 token 真正钉进代码里，防止开发绕过颜色、间距、排版等规则。适合新项目从首个 commit 建立约束，也适合把老项目逐步迁移到 token，或当硬编码样式不断回归时用它来锁死做法。特别之处是把“token 文件”变成代码层的守卫（guards），能写、扩展、调试这些守卫并处理迁移冲突。
▸ 展开 SKILL.md 英文原文
Build and enforce a design system inside a codebase — token tiers that nothing can skip, and guards that stop the code from drifting off them. Works for both new and existing projects, which need different guards. Use when starting a project and setting up tokens and enforcement from the first commit, when installing design-system enforcement on an existing repo, when tokens exist but nobody uses them, when hardcoded colours/spacing/typography keep reappearing, when deciding between a ratchet and a hard rule, when a design-system guard needs writing, extending or debugging, when migrating a large codebase onto tokens without a red build from day one, or when a "we have tokens" system is not actually being consumed. The code-side counterpart of figma-generate-library and figma-code-sync.
帮我安装这个 skill：https://raw.githubusercontent.com/zatteogit/design-system-skills/main/skills/design-system-code/SKILL.mdcurl -fsSL "https://raw.githubusercontent.com/zatteogit/design-system-skills/main/skills/design-system-code/SKILL.md"# Design systems in code A design system in code is **a consumption contract, not a token file**. Writing the tokens is a day of work. Making it impossible to bypass them is the system. This skill is the code-side half of the chain: `figma-generate-library` builds the system in Figma, `figma-code-sync` keeps the two aligned, and this one makes the code side worth aligning to. ## 0. The premise: a tier is only real if nothing skips it The same rule as the Figma side, and it is the whole discipline. Naming a token `semantic` does not make it a tier. **The test is consumption, not naming**: if components bind primitives directly, the primitives *are* the public API, whatever the folder is c