/god-review

Work out the change set: git diff <base>...HEAD plus uncommitted work. The base defaults to the main branch or the last release tag.
Get the review from a fresh context. You choose how: any subagent your host offers, a separate session, or another tool, run however suits the work. Before you start the reviewer, say which model and effort you picked for it and why, then pass both explicitly (whichever your host accepts); never let it inherit yours. Size both to the change: a fast model at low effort for a small, low-risk diff; the most capable model at high effort for auth, data, money, or concurrency changes. Give the reviewer the diff scope, the requirements (from PLAN.md, or listed under Goal in STATE.md), relevant DECISIONS.md entries, the verify command, and this brief, but not your own conclusions:
- Correctness: does the change meet each requirement and its check, including error paths and unusual inputs?
- Tests: does each requirement have a test, including the cases that must not trigger it? A test that would still pass with the behavior broken is a finding; name the missing case.
- Blast radius: what depends on the changed code? Name the one fact that must hold for the change to be safe, and how it was proven.
- Safety and fit: input validation, auth, secrets, destructive operations, data loss; existing patterns, no scope creep.
- Output: findings as severity: what, where, why, then pass or fail.
Fix each finding or state why not. Critical and high findings you leave open go under Risks in STATE.md.
If you changed code, record the check once after the fixes: npx -y godpowers@7 verify "<verify command>". After a large fix, review the new diff again.
Record the outcome on the final code: npx -y godpowers@7 record review --pass --summary "<one line>", or --fail with the reason.
When the review passes, set stage: harden in STATE.md if a security pass is due (the change touches a trust boundary, or the user asked to ship), otherwise stage: done.