Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →sangrokjung/review-loop
Run the adversarial verification loop — implement, then hand the change to a fresh checker that did not write it, fix what it finds, and re-dispatch until APPROVE. Use before claiming any behavioural change is done, and on requests like "review loop", "adversarial review", "independent review", "get this verified", "is this actually done", "maker checker", "second pair of eyes on this change". Not for prose, docs or typo edits.
Passed 22 of 23 test cases with the skill, and 13 of 23 without it.
and 12 more in the full report
9 fixed13 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
The original developer who wrote the feature branch offered to act as the fresh reviewer for round 2 after another agent requested changes. Can we assign round 2 review to this original developer?
| Checked | Without skill | With skill |
|---|---|---|
| Prohibit any past maker from acting as an adversarial checker for that change. | Passed | Passed |
| Require dispatching a checker with a fresh context. | Missed | Passed |
The instructions your model reads when the skill loads.
Nobody grades their own exam. The maker implements, a separate fresh checker tries to break the claim, and the two alternate until the checker approves the code as it stands right now.
Any change to behaviour: executable code, shell/Python/JS/TS/SQL, CI/CD, hooks, commands, agent and skill definitions, runtime prompts, and configuration that changes what the system does.
Exempt: prose documentation, marketing copy, typos, and formatting that cannot change behaviour. When a documentation-only change also touches something a runtime reads, it is behavioural. If you are unsure which side a change falls on, treat it as behavioural.
File count and diff size are not exemptions. A one-line change to an authorization check is behavioural; a 900-line documentation reflow is not.
| Risk | Lanes required |
|---|---|
| Ordinary behavioural change | 1 independent checker |
| Auth, authorization, payments, access-control rules, secrets, destructive data changes, irreversible deploys | 2 lanes, run by different checkers: correctness plus the risk-specific angle (runtime security, or rollback) |
maker implements → targeted test / real-surface QA → fresh checker
↑ │
└────────── REQUEST_CHANGES ← findings ──────────────┘
│
APPROVE on current code → done
There are exactly three verdicts: APPROVE, REQUEST_CHANGES, UNVERIFIED.
test cases passed, vs 13 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.