design-enforce
Skill1 starsChanged 44 days agoMITView on GitHub
Installs a lint script that works in any framework and flags one-off bracket values, hex codes, off-scale spacing and font sizes, and Tailwind colors used instead of named roles. Builds its config from the project's own tokens, records a baseline so CI only fails when things get worse, and can check shadcn/ui components. Use as phase 5 of design-system, after design-apply.
In this repository9 other files it gives its agents.
- apply-transitionsSkill
- beautifySkill
- choose-iconsSkill
- design-applySkill
- design-extractSkill
- design-grillSkill
- design-ratifySkill
- design-systemSkill
- empty-statesSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 0 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
Add it to package.json:
- Very specific: line 29
Write .design/lint.config.json using the values in DESIGN.md, not the defaults built into the script.
- Very specific: line 59
Keep raw-palette as a warning while the code is being migrated, and change it to an error after batch 3 of design-apply is done.
- Very specific: line 71
Put // design-lint-disable on a line to skip it, and always include a reason in the comment.
- Very specific: line 75
Do this only if components.json exists.
- Very specific: line 79
Follow the four steps in references/shadcn-alignment.md: fix components.json, check the files in ui/ for hard-coded values and local edits, …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Design Enforce
Install a lint script that flags any value outside the design system, using the project's own tokens as its rules.
Why a script and not an ESLint rule
ESLint rules read JavaScript and JSX. They can't see Svelte markup, Vue templates, Astro files or plain HTML. assets/design-lint.mjs reads files as plain text, so it works the same in every framework and needs no plugins.
Install
mkdir -p .design scripts
cp <skill>/assets/design-lint.mjs scripts/design-lint.mjsAdd it to package.json:
{ "scripts": { "design-lint": "node scripts/design-lint.mjs" } }Config
Write .design/lint.config.json using the values in DESIGN.md, not the defaults built into the script.
{
"include": ["src"],
"extensions": [".svelte", ".tsx", ".jsx", ".vue", ".astro", ".html"],
"spacingScale": ["0", "1", "2", "3", "4", "6", "8", "12", "16"],
"textScale": ["xs", "sm", "base", "lg", "xl", "2xl", "3xl"],
"radiusScale": ["none", "sm", "md", "lg", "full"],
"semanticColors": ["background", "foreground", "primary", "muted", "accent", "card", "destructive", "border"],
"allowRawPalette": false,
"exceptions": []
}spacingScale and textScale must match DESIGN.md exactly. If they don't, the linter enforces a different system from the one the docs describe.
Rules
| Rule | Level | What it flags |
arbitrary-value | error | one-off bracket values like p-[13px] or w-[327px] |
raw-hex | error | hex codes like #3b82f6 in markup |
off-scale-spacing | error | spacing like p-7 when 7 isn't one of the spacing sizes |
off-scale-text | error | font sizes like text-7xl that aren't in the type scale |
raw-palette | warning | Tailwind colors like text-neutral-700 used instead of a named role |
off-scale-radius | warning | one-off corner radius like rounded-[3px] |
Errors make the script exit with a failure. Warnings don't.
Keep raw-palette as a warning while the code is being migrated, and change it to an error after batch 3 of design-apply is done. Tell the user this is the plan when you install it.
Baseline
On an existing codebase, the first run usually finds hundreds or thousands of problems.
Save that number as the baseline in .design/lint.config.json, and set CI to fail only when the count goes above it. Don't make CI fail on every finding. A check that can never pass gets switched off, and a switched-off check looks like it's working while catching nothing.
Lower the baseline as each design-apply batch lands.
Exceptions
Put // design-lint-disable on a line to skip it, and always include a reason in the comment. Without a reason, nobody can tell later whether the exception is still needed.
shadcn/ui components
Do this only if components.json exists.
shadcn/ui copies component source files into the repo instead of installing them as a package. Over time they drift away from the originals and from each other. And a problem inside a shared component spreads: a Tailwind color hard-coded in ui/button ends up on every button in the product.
Follow the four steps in references/shadcn-alignment.md: fix components.json, check the files in ui/ for hard-coded values and local edits, replace hand-built components that duplicate shadcn ones, and treat findings inside ui/ as errors.
Optional extras
Offer these, but don't install them without asking.
A pre-commit hook:
echo 'npm run design-lint --quiet' >> .husky/pre-commitA CI step that runs npm run design-lint.
Report
Give the number of findings per rule, the three files with the most findings, and the baseline. Say which rules currently fail the build and which only warn.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

