The UI review
What it is. A screen-by-screen look at a product's REAL screens against the house doctrine, producing a document where every finding names a visible element and proposes its repair in plain words. Frank gives the verdict; a build session applies it; the screens are re-captured.
When it happens. Before anything that shows the product to outsiders: a user manual, a presentation, a pilot. Making a manual is always the occasion for a review.
Who does it. The agent ui-reviewer. It reviews, it never implements.
The grammar of a finding
One line, four parts. The visible element · what is wrong · why it matters (one clause) · the repair in plain words. Never a vague impression, never a fix written in code.
Three severities. bloquant a pilot customer stumbles · gênant it erodes trust or wastes gestures · finition polish. The ranked « ten repairs that matter » open the document.
Honesty both ways. A clean screen gets one line, « this screen is good », and the review moves on. Inventing problems to seem thorough is a fault.
What the reviewer checks, screen by screen
The 5-second test. Cover the text: does the screen still say what it is, what to do, whether all is well?
The one job. What did the user come to do, and is that the clearest thing on the screen?
Aligned to what. Every element must answer; floating badges and pills are findings.
Desktop honesty. A phone layout stretched edge to edge on a desktop screen is always a finding.
Honest words. The product's lexicon, names spelled as the brand writes them, an asterisk only where a field is really required, a placeholder that cannot be mistaken for a value.
The missing gestures. Forgot password, empty states, error states: absence is a finding too.
The separation law
The review never lives inside the user manual. The 
manual shows the product at its best for its future users; the review carries the faults and repairs for the maker. Two documents, two readers, one loop: verdict, repair, re-capture.
What it looks like
The other half: a page you made
Two reviews, one practice. The review above looks at a product's screens. Its sibling looks at one page you made — a document, a leaflet, a site page, a presentation — and comes back with comments on how to improve it. Say « review this page » and it runs. Skill: page-review (built 15-08-2026).
It asks one question first. Is this page a document, read calmly, or a pièce, whose job is to make someone feel something in three seconds? A pièce suspends six house rules (
README § Two modes), so a reviewer that guesses wrong flattens the page it was asked to improve.
What it measures, in the real rendered page. Headless, at desktop and phone width: stray values against the tokens, line length, body size and rhythm, typed fields under 16px, light background in every band, sideways scroll on a phone, console and network errors. Then it photographs the page in colour and again with all colour removed, because anything that loses its hierarchy in grayscale was leaning on colour to do structural work.
What it will not do. Give a score. Edit the page. Run the house audits on a pièce. And it says out loud when a page carries none of the markers the composition audit needs — a silent pass is not approval.
Where taste stops. Whether the page is beautiful is not measurable. We tried numbers once and the verdict was « stop, it is very ugly » (taste §2). The five-second test and « what is the one job » come back as questions for Frank, never as settled faults.
For the AI
Agent: ui-reviewer (agents/ui-reviewer) for a product's screens · skill page-review (skills/page-review) for one page, which drives token-audit.py and composition-audit.js and returns the captures. Doctrine it loads: Frank's baseline UX, the Kennedy digests, the Teletubbies principle, the product's design tokens and lexicon. First review: Vox Populi, 12-08-2026. Manual counterpart: the user manual.