code-reviewlisted

# Code Review ## Iron Law `FINDINGS FIRST. BLOCK ON CORRECTNESS, SAFETY, DATA LOSS, AND UNPROVEN CLAIMS.` ## When to Use - Self-review of your own implementation diff in the `workflow` completion loop after proving behavior with `proof`, before claiming done. Default for any non-trivial agent-generated change; a second pass by the same agent reliably surfaces bugs, dead code, and missed edge cases the implementation pass overlooks. - Diff review (local, branch, or GitHub PR via `gh`). - Review-comment follow-up on the user's own PRs. - Agent-generated code review before merge or handoff. ## When NOT to Use - Commit grouping or git history repair only; use `git-workflow`. - A narrow domain-only review where a specialist skill is sufficient (`security`, `database`, `api`, `accessibility`). ## Core Ideas 1. Review owns defect discovery, not proof execution. It should find behavioral bugs, regressions, unsafe edge cases, missing evidence, and merge blockers; `proof` owns turning claims into checks. 2. Findings first. Summaries, compliments, and change descriptions come after concrete issues ordered by severity. 3. Every review includes a security pass and a proof-evidence pass. If the review cannot verify a claim, report it as unproven. 4. Repository constraints beat generic advice. Check declared runtime, framework, dependency, CI, and support-policy constraints before using a language reference. 5. Maintainability findings need a concrete ris