Written guidance drifts. The model reads it, agrees with it, and violates it on the fourth screen. So the rules are held three different ways — and the strongest of them do not depend on the model’s judgement at all.
The conventions the model loads with the project: how a figure earns its place on a screen, what a status value is, which states have to exist before a screen counts as finished. This is the layer that shapes the first draft, and the layer that can drift.
Where a rule can be built into a component instead of written in a file, it is. The rule stops being advice the model can agree with and forget, and becomes something the output has no way to express. These are the rules that survive a model that disagrees.
What is left gets audited before anything is handed over. Figures are traced back to named data, status values are confirmed as a closed set with defined transitions, and layouts are verified from phone width to wide desktop. And where the answer is genuinely unclear, it stops and asks.
A file the model loads, a component that will not accept a wrong value, and a pass that reads the result before anybody else has to.
01One figure, all three →A list footer on an invoices screen. Nothing about it is interesting, which is exactly why it is usually wrong.
02Straight answers →The rules say a figure names the data it comes from, so the footer must be able to point at an array rather than a number.
The component takes source and derives its own range and total. There is no total prop to pass, so there is nowhere to type one.
The audit confirms the total matches the filtered set, and that an empty result renders its own state rather than 0 of 0.
The questions a sceptical lead asks before they will put an unfamiliar file in front of their team.
03What goes wrong without it →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
The components are the easy part. What you are missing is the layer that decides what gets computed, what gets shown, and what gets refused.