rate-my-code · Staff-level product scrutiny
Finished is not shippable.
Your app works. That is not the same as safe to ship. This one actually uses it — buys something, breaks something, tries to read another person's data — and shows you what happened. Every problem it finds, listed. Three to start with.
Issue list
BLOCKER · F-001Retrying a failed checkout creates a second charge — one purchase can bill the customer twice.
HIGH · F-004Any signed-in user can open another user's order by changing the id in the URL — private purchase history crosses the ownership boundary.
To verify
UNKNOWN · U-002Refund and cancellation have never been exercised end to end — the money path is only half proved.
Evidence lanes
Scope
What it actually audits.
Only things that would actually hurt someone using it. It will not tell you your code is ugly.
What the product promises, and the two or three things that have to work or the promise is empty.
Money: can it charge twice, charge half, lose a refund, or count the same payment message twice?
Can one customer see another customer's data by changing a number in the address bar?
What happens when someone clicks twice, two people act at once, or a save is cut off halfway.
The whole life of an account: sign up, upgrade, cancel, delete, take your data out, come back.
When it breaks at three in the morning, does anyone find out — and can you put it back?
With and without
What changes once it is installed.
Any decent AI will read your code and have opinions. This is the list of things it will not do unless this is installed.
Without it
It reviews whatever files happen to be nearby and produces findings about them.
With it
It looks, tells you ./missing-app is not there, and stops. It does not quietly review some other folder instead.
Without it
It picks a bar for you, usually the strictest or the friendliest, and never says which.
With it
It asks two things: who should review this, and how hard. If you already answered one, it only asks the other.
Without it
It reports code smells as if they were confirmed failures, or refuses to say anything.
With it
It says it could not run the app, reads the code instead, and marks what it finds as reasoning rather than proof. It will not approve a launch on reading alone.
Without it
It reads them separately and finds nothing, because each one is internally consistent.
With it
It lines the three up side by side, spots that one says 30 days and another says never, and names every page that has it wrong.
The part every other review skips
Then who reviews the fix?
Most reviews end at the list. If yours goes on to fixes, remember what a fix is: the newest code in the project, written in a hurry to close something, with no test of its own and nobody having read it.
The pass that writes the fix never grades its own work.
Whoever made the fix does not get to be the one who says it worked. Someone else checks.
A diff is not a fix.
Every finding ships with the exact test that would close it. A finding reaches verified-fixed
only when that separate context reproduces the original failure and watches it stop happening.
The patch itself gets audited.
That same context treats the change as new surface and reviews it under the same rubric. Defects introduced by the fix open as new findings with new IDs, and the batch stays open until they are resolved.
The loop ends on evidence, not on an empty list.
It stops at verified closure, at a named blocker, or when you accept the remaining risk out loud — recorded as accepted risk, never quietly reclassified as fixed.
This site was audited this way. The independent pass found two defects in the patches written to close the first round — a stale backup left publicly readable, and a skip link whose focus never reached the content. Both were introduced by the fixes, and neither would have surfaced from re-running the original tests.
How it runs
Two settings, then evidence.
It asks. It will not quietly pick the harshest setting for you, or the kindest.
Reviewer setting
Product lead / Hostile user / Staff engineer / Staff Frontend engineer / Skeptical VC / Oral-defense examiner
Review degree
Quick checkup / Strict review / Launch gate / Real-revenue tier / Life-or-death
No score averages away a veto.
Some problems stop a release no matter how good the overall score looks. Saying you can live with one does not turn it into a pass.
Start with the quick check.
It is the default because a full-degree audit costs several times more in time and tokens. The cheaper degree reaches fewer things — and says so — rather than reporting less of what it found.
The five
One evidence contract, five layers.
Each installs on its own. Take the one that matches what you are shipping.
Install
One command, or a plugin marketplace.
One method per client. The first pass only reads — it changes nothing — and your own sandbox and approvals still decide what it is allowed to touch.
npx skills add AmsonntagChow/rate-my-code --skill rate-my-code
/plugin marketplace add AmsonntagChow/rate-my-code
codex plugin marketplace add AmsonntagChow/rate-my-code && codex plugin add rate-my-code@amsonntagchow-rate-my-code