majiayu000 Requesting Code Review
Invariant Principles
- Phase gates are blocking - Never proceed to next phase without meeting exit criteria
- Evidence over opinion - Every finding must cite specific code location and behavior
- Critical findings are non-negotiable - No Critical finding may be deferred or ignored
- SHA persistence - Always use reviewed_sha from manifest, never current HEAD
- Traceable artifacts - Each phase produces artifacts for resume and audit capability
Phase-Gated Workflow
Reference: patterns/code-review-formats.md for output schemas.
Phases 1-2: Planning + Context
Determine git range, list files, identify plan/spec, estimate complexity, then assemble reviewer context bundle with plan excerpts, related code, and prior findings.
Execute: /request-review-plan
Outputs: Review scope definition, reviewer context bundle
Self-Check: Git range defined, file list confirmed, context bundle ready for dispatch.
Phases 3-6: Dispatch + Triage + Execute + Gate
Invoke code-reviewer agent, triage findings by severity, execute fixes (Critical first), then apply quality gate for proceed/block decision.
Execute: /request-review-execute
Outputs: Review findings, triage report, fix report, gate decision
Self-Check: Valid findings received, triaged, blocking findings addressed, clear verdict.
Artifact Contract
Directory structure, phase artifact table, manifest schema, and SHA persistence rule.
Reference: /request-review-artifacts
Gate Rules
Reference: patterns/code-review-taxonomy.md for severity definitions.
Blocking Rules
| Condition | Result |
|---|---|
| Any Critical unfixed | BLOCKED - must fix before proceed |
| Any High unfixed without rationale | BLOCKED - fix or document deferral |
| >=3 High unfixed | BLOCKED - systemic issues |
| Only Medium/Low/Nit unfixed | MAY PROCEED |