ControlFlow Review
Overview
ControlFlow Review is a layer over Claude Code's native review capabilities, not a
replacement. Mechanical and style review (lint-class issues, formatting, rote pattern
checks) belong to native /code-review and security-review. This skill adds only what
native review does not provide: plan-vs-implementation scope-drift comparison,
evidence-backed finding discipline, and proactive vulnerability/error search.
Invoke this skill via /controlflow-claude-code:controlflow-review.
Local Contract
- Run native
/code-review(orsecurity-reviewfor security-focused work) first for the mechanical pass; this skill consumes and augments its output rather than duplicating it. - Compare the implementation to the plan when one exists — scope drift is a review issue, not a style preference.
- Findings first, ordered by severity, with file/line evidence and confidence.
- Distinguish validated blockers from hypotheses; state validation gaps explicitly.
- Use references/review-checklist.md, references/validation-status.md, references/evidence-discipline.md, and references/security-review-discipline.md for shared checklist and evidence discipline, and ../controlflow-plan/references/llm-behavior-guidelines.md for generic anti-rationalization discipline.
Workflow
- If a plan exists at
plans/<task-slug>-plan.md, read it. Track every phase acceptance criterion and file the plan said it would touch — anything implemented but not planned, or planned but not implemented, is a scope-drift finding. - Delegate the mechanical/style pass: invoke native
/code-review(orsecurity-review) and collect its findings. - Add the ControlFlow layer:
- Plan comparison — does the diff match the plan's phases, files, and acceptance criteria? Flag scope drift, missing phases, extra-phased work, and unmet acceptance criteria.
- Vulnerability / error search — proactively hunt for bugs, regressions, data integrity issues, and security defects the mechanical pass may miss. Validate suspicions with commands, file reads, or schema checks.
- Evidence discipline — label each finding with severity, confidence, file, line, user impact, and validation method.
- Present findings first, ordered by severity. If there are none, say so and name residual risks or test gaps. Use structured text, not raw JSON.
Review Axes (ControlFlow layer)
Prioritize correctness/functionality, security, data integrity, regression risk, and
contract drift before style. Maintainability/style comments should support a behavioral
risk, not bury one — and the mechanical side of style is native /code-review's job.
Proactive Vulnerability / Error Search
Go beyond reactive review of the diff:
- Trace new data flows to their endpoints; check validation at each boundary.
- Look for error paths the implementation skipped (absence mirages A11–A13).
- Check for missing migrations or rollback for schema/contract changes (A16).
- Check for missing security boundaries on sensitive operations (A17).
- Where the plan declared failure expectations, confirm the implementation handles them.
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
FYIwhen the untested behavior can regress. - Do not state a blocker without validation evidence or an explicit unconfirmed-risk label.
- Do not duplicate native
/code-review's mechanical pass — delegate it. - Do not skip the plan comparison when a plan artifact exists.
References
references/review-checklist.mdreferences/validation-status.mdreferences/evidence-discipline.mdreferences/security-review-discipline.md../controlflow-plan/references/llm-behavior-guidelines.md