| name | controlflow-review |
| description | Use after implementation to review a diff or completed phase. A thin ControlFlow layer over Claude Code's native /code-review: adds plan-vs-implementation scope-drift comparison, evidence discipline, and proactive vulnerability/error search. Does not duplicate native review — delegates mechanical/style review to /code-review. |
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
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 (or security-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
FYI when 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.md
references/validation-status.md
references/evidence-discipline.md
references/security-review-discipline.md
../controlflow-plan/references/llm-behavior-guidelines.md