code-review-methodologylisted

# Code Review Methodology ## Contract Iron law: first verify it works, then verify it is good; never review quality on code that does not meet the acceptance criteria. Loaded as a Required Skill by `/flow:review` (all phases) and `/flow:pr` (self-review and fan-out), and by the `code-reviewer` and `security-reviewer` agents. Returns a synthesized P1/P2/P3 finding set per `references/finding-schema.md`, a requirements-compliance map, and a decision (APPROVE, COMMENT, REQUEST_CHANGES). Permitted skips: Stage 2 is skipped when Stage 1 finds more than 3 unmet criteria (REQUEST_CHANGES immediately); on the 3rd+ review cycle only new P1s are raised. ## Two-stage review **Stage 1, spec compliance.** Map each acceptance criterion to implementation evidence with one status: **Met** (implemented and testable), **Interpreted** (criterion ambiguous; one reading implemented), **Partially Met**, or **Not Addressed**. If Stage 1 fails, stop. **Stage 2, code quality**, in priority order: security, correctness, performance, maintainability. Do not flag maintainability while security or correctness findings exist. ## 6-facet review Stage 1 runs first on the main thread; facets fan out in parallel: | Facet | Focus | Agent / Skill | |---|---|---| | **Security** | OWASP top 10, secrets, auth/authz, input validation | security-reviewer | | **Quality** | Logic correctness, edge cases | code-reviewer | | **Conventions** | Commit format, branch naming, PR structure | convention-checker | | **