ui-consistency
CLAUDE.md1 starsChanged 7 days agoMITView on GitHub
A plugin, Claude Code first with manifests for Codex, Cursor, Copilot CLI and Gemini CLI, that makes a project's own design system AI-aware, read from the code it already has. Before an agent writes UI, it reads how the pages are built and writes the new one the same way: the right component written the way the other pages write it, the project's own validation and error handling, values from the theme, repeated code turned into components. The way of…
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- uic-auditingSkill
- uic-writingSkill
- accessibilitySkill
- adjustingSkill
- conventionsSkill
- decisionsSkill
- designSkill
- finding-patternsSkill
- implementingSkill
- planningSkill
- valuesSkill
- verifyingSkill
The file
We split this CLAUDE.md into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 26
Read before proposing anything: docs/concept.md, then skills/.
- Distinctive: line 88
The developer's agent does the reading: No scripts, parsers or commands for analysis.
- Distinctive: line 112
A plan carries its check: Every page task carries its checklist and is verified by an agent that did not write it, with a check proved …
- Distinctive: line 118
Silence is never success: Every phase says what it read and what it could not.
- Distinctive: line 120
Free: No licence checks, telemetry or paywalls.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md 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
CLAUDE.md
What this is
A plugin, Claude Code first with manifests for Codex, Cursor, Copilot CLI and Gemini CLI, that makes a project's own design system AI-aware, read from the code it already has. Before an agent writes UI, it reads how the pages are built and writes the new one the same way: the right component written the way the other pages write it, the project's own validation and error handling, values from the theme, repeated code turned into components. The way of working is Design-Driven Development: what the end user sees drives the code, so a page comes out consistent and right while it is being written rather than corrected afterwards.
The design is read wherever it lives — a design for the page, the theme and
its tokens, a DESIGN.md, or the pages already built, which is the usual case.
It is skills and nothing else. The only code is the session hook.
It does one thing and joins whatever else is running. Another process keeps the plan, the tests and the logic; this one makes what the end user sees come out like the rest, so nobody opens the page afterwards and fixes it by hand. It writes no tests and never starts a test suite.
Read before proposing anything: docs/concept.md, then skills/.
Layout
skills/— five phases,finding-patterns,adjusting,planning,implementing,verifying, and five subjects:designandaccessibility, each asked on its own or reached from a phase, andvalues,conventionsanddecisions, reached from the phases: a step that needs one names it as a skill to invoke, never as a link. A file of any other skill that a step reads is its path written out, never a link: a catalog's linter fails a skill whose link leaves its folder. Each is reached by itsdescription, in any language. A phase is a gerund with no object, a subject skill is a noun — that is how the two kinds are told apart in a listing. The plugin's own name carries the domain, so no skill name repeats it; where a harness shows no namespace the description carries the whole weight, so it says in its first words that the work is what an end user sees.USING.md— what the plugin tells a user's agent: which skills a job takes, in what order, and where to report a page that came out wrong. The session hook says the same; Gemini CLI loads this file throughGEMINI.md, which includes it.AGENTS.md— the contributor guidelines for an agent working in this repository, insuperpowers' shape; included below, and read on its own by harnesses that do not read this file..claude/skills/— skills for working on the plugin, which an installed plugin never loads:uic-writing, how a skill or document here is written and what is checked after — loaded when one of those files is being changed; anduic-auditing, run when somebody asks for an audit or runs/uic-auditing, which checks everything against the current guidance and proposes issues.hooks/session-start— a short bash script, run by theSessionStarthook (hooks/hooks.json, throughhooks/run-hook.cmd, which finds bash on Windows). It printshooks/session-context.md, which tells the session which skills a job takes and in what order, and where to report a page that came out wrong. It needs no Node and installs nothing. It has no off switch of its own: a harness disables a plugin its own way, and a switch in the hook could silence only the hook, never the skills.- Nothing is written into a project's repository. A plan lives in the
session, in a scratch file outside the working copy, attached to a story, or
inside another process's plan — the three endings of
planning— and goes with the work.
Nothing may assume a hook is running. An install from this repository runs
the session hook; an install from release runs none: hooks/ is left out of
it, because Anthropic's directory, which reads release, holds a command hook
from an organisation it has not verified.
- Claude Code runs the hook when installed from this repository's marketplace, and has been run end to end; from Anthropic's directory it gets the skills alone.
- Codex is installed from
releaseand gets the skills from its manifest. Installed frommain, it runs the hook fromhooks/hooks.jsononce the user trusts it in/hooks; run end to end on the acceptance test (#368). - Copilot CLI reads its own
plugin.json, a legacy plugin with no$schema, and gets the skills and the hook; not run end to end. - Cursor has a session-hook manifest; not run end to end.
- Gemini CLI loads
USING.mdthroughGEMINI.md; not run end to end.
The private kamenkurtev/ui-consistency-archive holds the history before this
repository's single root commit, and the old tracker. Issue numbers here point
to this repository only — both trackers start at 1.
What the design rests on
- The developer's agent does the reading. No scripts, parsers or commands for analysis. Every analysis program this project wrote became thousands of lines that kept being wrong.
- Roles, never names. Skills and examples say page holder, field, submit button, the shared error helper. No framework's or library's component or prop name — every technology builds a page differently.
- Universal. Any UI technology, including plain HTML and CSS; a single app or a monorepo. Structure is read from the project, never required as config.
- A named reference outranks a count, and a count carries its spread — where the component stands, and in how many files.
- It decides and reports; it does not interrogate. A written order settles what a count alone cannot, and every decision carries the level that settled it and the numbers. Three things wait on a person: the plan, shown for a yes; a tie in the order whose answer changes code outside the task; and a new component the request did not name with its place, or code extracted into one, asked on its own with what it touches. Other proposals and contradictions are reported, with the plan where there is one. A request that says two things at one position, or leaves open what the page must show, is reported as blocking, and only the positions it touches wait on the answer.
- Join the process that is running. A spec or plan that a running process keeps is added to, not duplicated; one left by an earlier run is evidence, worked out again from the code. Without one, the skills run the phases themselves.
- A plan carries its check. Every page task carries its checklist and is verified by an agent that did not write it, with a check proved first to catch a difference planted by somebody else. Nothing is kept that can be worked out again: counts belong to the task and go with it. Only a person's override of the order outlives one, where the running process records decisions; with none, it is reported and not kept.
- Silence is never success. Every phase says what it read and what it could not.
- Free. No licence checks, telemetry or paywalls.
Working here
- A skill change comes from real work: a page built with the plugin that came out wrong becomes an issue. The issue closes when its pull request merges. Whether the change works comes from feedback the next time the plugin is used, and whether that becomes a new issue is decided then. There are no dedicated test runs.
- Designs and plans go on the issue, not into
docs/. - The checks cover the hook, the manifests and the skills' structure — never
the skills' wording, which real work checks. They are bash and perl, which
come with git; nothing to install.
scripts/check-skills.shfails on a skill outside the platform's limits or over 16,000 characters, a link, written-out path or skill name that points at nothing, a link that leaves its skill, a link or path from another skill intovalues,conventionsordecisions, a library component name in the skills orUSING.md, or a skillUSING.mdor the session text does not name.scripts/check-packaging.shfails on manifests that disagree, a Copilot CLI manifest that opts into Agent Plugins, a Codex manifest with ahooksentry or a listing field missing or over OpenAI's limits, a hook other than the one, a hook in whatreleasecarries, or a file an install would run npm on.scripts/check-hook.shruns the hook as each harness does.scripts/check-private-names.shfails on private names (seeuic-docs.md).scripts/test-checks.shplants a defect for each check and proves it fails.
- Commands:
scripts/gate.sh— everything a PR needs: the checks, the version check, the proof of the checks, plugin validate.scripts/bump.sh— cuts a release, when the owner decides: patch, orminor/majorby semver (uic-git.md, Versions). It moves the version in all six manifests and turns Unreleased into its section; merging it tags the release. A pull request that is not a release adds its line under## Unreleasedinstead.
Rules
The contributor guidelines — what every agent working here does before a pull
request, and what is not accepted — are AGENTS.md, the file harnesses other
than Claude Code read. One copy, included here:
@../AGENTS.md
Detailed rules live in .claude/rules/, each prefixed uic-:
@rules/uic-docs.md @rules/uic-git.md @rules/uic-pr.md @rules/uic-subagents.md
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.

