Review an App

Look at an app that already exists and say what is wrong with it. Not what a different, larger, more mature app would have — what this one gets wrong about itself.

This is not a code review and not a deploy gate. /code-review reads the pending diff and is blind to anything already wrong before this branch. deploy-an-app asks whether a deploy will land. start-an-app's critics measure against a build sheet written the day the app was scaffolded. All three are anchored to something other than the app, which is why an app six months in has drifted past all of them. This skill reviews the thing itself, as it is now.

Ground rules

• The app is its own spec. There is no build sheet here and nothing to measure against except the app's own claims — what the landing page sells, what the docs instruct, what the privacy policy promises, what the sitemap invites a crawler to open, what a button implies when it renders. A finding is a contradiction between what the app says and what it does. Anything else is a suggestion, and suggestions are not findings.
• Absence is not a finding. "No rate limiting", "no tests", "consider adding structured data" — none of these are things the app got wrong. They are things a bigger app would have. The single fastest way to make this skill worthless is to let it list what a mature product does; that report gets skimmed once and never again.
• Read-only. This skill does not edit the app. It runs commands that read, it may serve the app to probe it, and it changes nothing. Fixing is a separate, explicit ask — Step 6, and only when the user says so.
• Consequence, not pattern. Every finding says who is affected and how. "This query isn't scoped by user" is a pattern; "any signed-in account can read every other account's invoices by changing the id in the URL — src/app/invoices/[id]/page.tsx:14" is a finding. If the path from the outside world to the flaw can't be described, it isn't one yet.
• A check that wasn't run is named, never claimed. The same rule the rest of this family runs on. Where the app wouldn't start, where a key was absent, where a route needed a browser — say which check that cost, and what it would take. Silence reads as a pass.
• Never conclude that the app is secure. No review establishes that. The honest closing sentence names what was checked and what wasn't; "no vulnerabilities found" is a sentence this skill must never produce, because it will be quoted back later by someone who has stopped looking.
• The user's choices are not findings. A stack you'd have picked differently, a design you don't like, a deliberate decision to keep an app out of search — none of these are wrong. Where a choice looks like an accident, report the evidence that it was an accident, not the choice.
• Never write or accept a version number. Not in a command, not in prose, not a package pin. Where a check depends on something that moves — AI crawler user-agent tokens, an advisory database, a framework's file conventions — establish it at review time.
• Lenses get evidence, not access. They cannot share a port or a browser, and a lens that can run things will spend its budget running things. Capture once in Step 2, hand it over, and let them read.

Step 1 — Orient