The stated layer asks. The compiled layer enforces. The audit is what catches everything in between — a pass over a finished screen that reports, by name, which rules it broke and where.
An audit that claimed to judge taste would be wrong constantly and trusted briefly. This one only reports things that are decidable by looking — which turns out to be most of what actually goes wrong.
01What it checks →Questions with an answer in the data or the markup, where a disagreement is a fact rather than an opinion.
Questions where the honest answer is a judgement. The audit does not have one and does not pretend to.
Every check names the rule it came from, so a finding is never a matter of style. If a rule is removed, its check goes with it.
02How it runs →Figures that summarise other figures, and whether the screen can say where each one came from.
11 checksEvery value present in the fixtures, and whether a screen exists for each one. Including the four states.
14 checksActions offered against the state of the record they sit on, and whether that state permits them.
9 checksRoutes, breadcrumbs and cross-references, and whether each one resolves to something that exists.
12 checksLabels that claim more than the data supports, and words the system was not given permission to invent.
8 checksIt reads a finished screen, so it can run at any point after there is something to read. In practice there are three that matter.
03Straight answers →Ask for the pass as soon as the screens exist. It is faster at finding a missing state than you are, and it never gets bored on screen six.
The findings are named rules, so the conversation with a developer starts from a list rather than from a feeling that something is off.
A new status upstream is the most common way coverage quietly breaks. Re-run the pass and it says which screens never heard about it.
Command-line run · on the roadmapWhat a reader asks once they have seen a pass run: what it costs them, what it misses, and what happens when it disagrees.
04Back to the top →It ships components and tokens, but that is not what you are buying. The product is the rules layer that decides what gets computed, what gets shown and what gets refused — plus the machinery that makes those rules checkable.
It is built for Claude Design users generating business UI. Because the layer is plain markdown loaded as project instructions, anything else that reads a rules file will use it too. There is nothing proprietary to integrate.
The tokens are yours to set and brand fit is a config change. The judgement rules are not configurable, because that is the product. If you want a different opinion about derivation, you want a different product.
The rules are written against behaviour rather than internals, so upstream releases move underneath them. Where a rule does need to change, it changes in one file you can read in an afternoon.
Marginally slower on the first generation. Considerably faster by the fourth, because you are not re-prompting it to fix a total that never tied.
Reckon
Components are the easy part. What you are missing is the layer that decides what gets computed, what gets shown, and what gets refused.