ControlFlow Plan Audit
Overview
Adversarially review a saved implementation plan before coding. Look for architecture defects, dependency mistakes, missing rollback, scope gaps, weak tests, and first-phase executability problems.
Local Contract
Workflow
- Read the saved plan artifact first, not a summary.
- Check file/path reality, available tests and validation commands, architecture/dependency surfaces, rollback, acceptance quality, contract completeness, and first-phase executability.
- Return one verdict:
APPROVED, NEEDS_REVISION, REJECTED, or ABSTAIN.
- For non-approval, classify as
fixable, needs_replan, or escalate.
- Save and summarize evidence-backed findings.
Spec-Before-Plan Health Check
For non-trivial work, confirm the plan is anchored to explicit requirements, acceptance criteria, constraints, exclusions, and verification gates rather than inferred chat context.
Audit-Specific Failure Checks
- Do not approve a detailed plan that lacks a spec artifact or equivalent requirements section.
- Do not approve vague success criteria; require measurable acceptance and gates.
- Do not downplay rollback gaps; classify them by blast radius.
- Do not accept plausible repository claims without checking current paths and commands.
Output Shape
- Status
- Findings
- Risk Summary
- Recommendation
- Failure Classification when needed
- Confidence
References
references/audit-checklist.md
../../templates/plan-audit-report-template.md
../controlflow-review/references/security-review-discipline.md
../controlflow-planning/references/llm-behavior-guidelines.md
1---2name: controlflow-plan-audit3description: Use when a saved implementation plan should be adversarially reviewed before coding, especially for small, medium, or large tasks that may contain architecture flaws, scope gaps, destructive risk, weak rollback, weak tests, or dependency conflicts.4---5
6# ControlFlow Plan Audit
7
8## Overview
9
10Adversarially review a saved implementation plan before coding. Look for architecture defects, dependency mistakes, missing rollback, scope gaps, weak tests, and first-phase executability problems.
11
12## Local Contract
13
14- Read the actual plan artifact and cross-check it against repository files, tests, commands, architecture, and dependencies.
15- Use [references/audit-checklist.md](references/audit-checklist.md) for audit coverage and [../controlflow-planning/references/llm-behavior-guidelines.md](../controlflow-planning/references/llm-behavior-guidelines.md) for generic evidence discipline.
16- Save the verdict to `plans/artifacts/<task-slug>/plan-audit.md` using [../../templates/plan-audit-report-template.md](../../templates/plan-audit-report-template.md).
17- Tie findings to plan sections or repository facts.
18
19## Workflow
20
211. Read the saved plan artifact first, not a summary.
222. Check file/path reality, available tests and validation commands, architecture/dependency surfaces, rollback, acceptance quality, contract completeness, and first-phase executability.
233. Return one verdict: `APPROVED`, `NEEDS_REVISION`, `REJECTED`, or `ABSTAIN`.
244. For non-approval, classify as `fixable`, `needs_replan`, or `escalate`.
255. Save and summarize evidence-backed findings.
26
27## Spec-Before-Plan Health Check
28
29For non-trivial work, confirm the plan is anchored to explicit requirements, acceptance criteria, constraints, exclusions, and verification gates rather than inferred chat context.
30
31## Audit-Specific Failure Checks
32
33- Do not approve a detailed plan that lacks a spec artifact or equivalent requirements section.
34- Do not approve vague success criteria; require measurable acceptance and gates.
35- Do not downplay rollback gaps; classify them by blast radius.
36- Do not accept plausible repository claims without checking current paths and commands.
37
38## Output Shape
39
40- **Status**
41- **Findings**
42- **Risk Summary**
43- **Recommendation**
44- **Failure Classification** when needed
45- **Confidence**
46
47## References
48
49- `references/audit-checklist.md`
50- `../../templates/plan-audit-report-template.md`
51- `../controlflow-review/references/security-review-discipline.md`
52- `../controlflow-planning/references/llm-behavior-guidelines.md`