| name | controlflow-review |
| description | Use when asked to review code, a diff, or a completed phase, especially when the result should emphasize bugs, regressions, validation status, and evidence-backed findings instead of style commentary. |
ControlFlow Review
Overview
Review changes by prioritizing correctness, regression risk, and evidence over style. Use this for code or completed-phase review; use controlflow-plan-audit or controlflow-assumption-verifier for pre-execution plan review.
Local Contract
Workflow
- Check correctness, regressions, security, data integrity, performance, and contract drift before style.
- Validate feasible suspicions with commands, file reads, or schema checks.
- Label each finding with severity, confidence, file, line, and user impact.
- Present findings first; if there are none, say so and name residual risks or test gaps.
- Use structured text, not raw JSON.
Review Axes
Check correctness/functionality, security, architecture/design, maintainability/style, and test quality/coverage. Style comments should support behavioral risk, not bury it.
Soft Comment Labels
Use Nit, Optional, and FYI only after blocking findings. These are not severity levels and must not hide correctness, security, or test coverage defects.
Change Size Caution
Large reviews lose signal. When a diff is much larger than roughly 100 changed lines or mixes unrelated concerns, ask for a split or review by file area and risk axis with an explicit confidence limit.
Review-Specific Failure Checks
- Do not lead with nits before behavior checks.
- Do not mark missing tests as
FYI when the untested behavior can regress.
- Do not state a blocker without validation evidence or an explicit unconfirmed-risk label.
References
references/evidence-discipline.mdreferences/review-checklist.mdreferences/validation-status.mdreferences/security-review-discipline.md../controlflow-orchestration/references/tdd-patterns.md../controlflow-planning/references/llm-behavior-guidelines.md
