Review agents

The patterns teach an agent how to build. These three check what it built, and they exist because of a specific failure: three products were built on this template by three independent agents, every automated gate stayed green, and the three came out looking like the same unfinished app. Nothing measured how any of it looked, so nothing objected.

design-critic

Reads screenshots, deliberately not source. Reading JSX and imagining the result is exactly the mistake that produced the problem.

It looks for dead gutters, missing hierarchy, opacity standing in for a text colour, numbers that do not right-align, statuses all rendered the same, tables whose rows are only links, empty states that read as bugs, skeletons that do not match their content, and placeholder copy left in.

On its first real run — over our own landing page, freshly migrated onto the design system — it pixel-measured the page and found that bg-muted/40 renders at #FBFBFB against a #FFFFFF page. A four-in-255 difference: a section band that cost code and delivered nothing visible. That is now fixed in the shared block, so every project gets the fix.

It also caught the FAQ being the one consumer of SectionHeader not using the shared eyebrow-and-subtitle shape — precisely the drift a shared frame exists to prevent — and a marquee mask that started inside its first item, clipping "Next.js 16" to "js 16" on the one row whose job is naming the stack.

copy-reviewer

Reads every user-visible string: microcopy, empty states, error messages, enum labels, and anything the product claims about itself.

The last of those matters most. src/config/billing.ts has had a sold-equals-real invariant since the beginning — every feature string in it must be a working, documented capability. Marketing copy never had one, and it is the surface a buyer reads first.

On its first run it found four claims on our own site that were not true, all phrased to invite verification:

• "CI builds an app from the previous release" — there is no previous release, and the workflow says so in its own comments.
• "Codemods that upgrade projects you generated months ago" — the registry is empty, with a docblock reading "Empty, and honestly so."
• "usage billing", which reads as billing your customers by usage through Stripe. What ships is per-plan quotas enforced in-app.
• "Most popular" on the only tier of a product nobody had bought — invented social proof arriving through a different door than the testimonials block refuses to open.

It also found two links nobody had clicked: a sidebar item pointing at a page that always rendered an error, and a docs link to a repository that is private.

seo-auditor

Fetches rather than reads. The highest-cost thing it looks for is a public route that returns a redirect to sign-in — src/proxy.ts lists public paths, so a new route is private by default, and /docs shipped that way once through a completely green build.

Beyond that: per-page metadata and canonicals, structured data that agrees with the rendered page, alt text that describes what an image shows, and a sitemap and robots file that resolve.

Using them

Each is a Markdown file with frontmatter naming its tools. Point one at a running app and give it screenshots or a URL.

The instruction worth copying into your own is this: a review that finds something wrong with everything is as useless as one that finds nothing. Both of these agents are told to say plainly which files and which screens were clean, and to report what is measurably inconsistent, illegible, unactionable or untrue — not what they would have chosen.