review-codelisted

# Code Review Be thorough but concise. **Use this when:** Reviewing code changes - bug fixes, new features, refactors, scripts. **Don't use this when:** Testing a running web app (/review-browser), reviewing slash command prompts (/review-commands), checking plan completion (/review-plan), evaluating UX (/review-ux), or doing a pre-release check (/review-full). ## Critical Rules <rules> 1. **THE REVIEW PHASE REPORTS ONLY** - Reviewing never edits files; findings are its product. After the report, the same run continues into the auto loop (rule 2), which is what applies fixes 2. **Audit, then auto-fix, with pages** - Code findings are audited before the report per M2 in `.claude/skills/shared/hitl-loop.md`, so the report shows survivors only plus an Audited out log for the kills. They do not then wait for a human "fix it": after the report, survivors are auto-fixed and re-verified, and each finding exits as page, digest, or log per `.claude/skills/shared/hitl-loop.md` (pages only per M1; saying "report only" keeps a run report-first, M10) 3. **Explain simply** - Use plain English, avoid jargon </rules> !`cat .claude/skills/shared/criteria-code.md` ## Reading Budget !`cat .claude/skills/shared/reading-budget.md` ## Severity Levels and Anchors !`cat .claude/skills/shared/severity-anchors.md` **Project severity anchors** (from `.claude/toolkit/severity-anchors.md`): this project's weighting for its own review kinds. The Universal Anchors above still win. A note that t