The stated layer is a single markdown document. It is read at the start of a session and it governs every screen after that — not a style guide, but a set of claims about what a business screen is allowed to do.
A total names the rows it totals.
Stated once, in the words a reader would use to argue with it.
A footer nobody can trace is a number nobody can defend.
The footer component takes rows and derives the sum. No prop to pass.
A rule with no reason gets argued with. A rule with no enforcement level is a preference wearing a uniform. Both parts are required, which is what keeps the file from drifting into taste.
01Where it shows up →A footer nobody can trace is a number nobody can defend. When a client asks where it came from, someone has to open the database.
Compiled The footer component accepts rows and derives the sum itself. There is no prop to pass, so the rule cannot be broken by ignoring it.
A model that knows only the instruction applies it literally and stops at the edges. A model that knows the reason extends it correctly to a case the file never named.
Three of these rules are enforced by the components themselves and cannot be broken. Most are not. Marking which is which stops a reader trusting a suggestion as though it were a guarantee.
Guidance split across a wiki is guidance nobody loads. One document, read at the start of the session, is the only version that survives contact with a real task.
It is not read once and filed. The rules file is quoted in the brief, loaded before the first screen is drawn, and read again by the pass that checks the result.
02What it covers →A figure that summarises other figures is computed from them. It is never accepted as a prop and never typed into a fixture, because a number that can be passed in is a number that can be wrong without anybody noticing.
Three of the eleven are held by the components themselves. The rest are stated, which means a reader can still get them wrong — and the audit will say so by name.
A work queue for marine cargo claims. It leads with the filing deadline, because a claim that goes time-barred cannot be recovered by anything the interface does afterwards.
Everything else about a queue is already written down in the shell, so the brief does not repeat it. That is the whole reason for having archetypes.
The file is read before anything is drawn, so the conversation starts at your three choices rather than at the basics. Nobody has to explain, again, that a settled record should not be offered an action it cannot honour.
Three of the sixty cannot be broken at all, because the components will not accept the shape that breaks them.
The pass reads the finished screens against the same file. Findings are named rules rather than opinions, so the conversation that follows starts from a list instead of a feeling that something is off.
One finding, with the rule number and the screens attached. Anything the audit cannot decide by looking, it does not mention at all.
Not colour, spacing or type — those are tokens, and they are somebody’s brand rather than anybody’s judgement. These are the decisions that make a business screen correct or wrong.
03How it loads →Where a figure comes from, and what may never be passed in as a number.
Mostly compiledWhich actions a record may be offered, given the state it is actually in.
Mostly checkedThe states that must exist before a screen is finished — empty, loading, denied, partial.
Mostly checkedWhat a label may claim, and the words a system is not allowed to invent.
StatedWhat belongs on a record page, what belongs in a queue, and what belongs to neither.
StatedThe three choices each shell must make on purpose, so two products do not arrive identical.
StatedIt is markdown. Every route below is the same file arriving in a different place.
04Straight answers →Drop the folder in. The file is read on load, before the first component is drawn.
SKILL.md carries the front matter already. The rules load with it.
Any model that reads context can be given the file. No install, no runtime, no assumption about the stack.
What a reader asks after seeing the file: whether it holds, what happens when it is ignored, and who has to maintain it.
05Back 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.