ControlFlow Verify
Overview
Verify a saved plan before implementation. The checks run inline in the current host
context with zero subagents shipped by the plugin. This skill combines the useful parts of the former
plan-audit, assumption-verifier, and executability-verifier workflows without reproducing
Codex subagent orchestration.
Select the skill explicitly. In Codex, invoke it with $controlflow-verify.
Input and Contract
- Read the plan from disk; do not verify a chat copy.
- If the active repository provides
schemas/planner.plan.schema.json and
plans/templates/plan-document-template.md, use them.
- Otherwise use
../controlflow-plan/references/plan-format.md.
Tier Gating
| Tier |
Verification |
TRIVIAL |
Skip unless explicitly requested |
SMALL |
Phase 1 |
MEDIUM |
Phases 1–2 |
LARGE |
Phases 1–3 |
Any unresolved applicable HIGH semantic risk requires all three phases.
Phase 1 — Structural Audit
- Check the header, section order, lifecycle headings, all seven semantic-risk rows, phase
shape, diagrams, exact commands, measurable acceptance criteria, and rollback guidance.
- Verify referenced paths and tests against the repository.
- Apply the Minimum Viable Change Ladder before accepting new abstractions, dependencies,
or generated surfaces.
Phase 2 — Assumption and Mirage Check
- Try to refute each factual claim that names a file, symbol, dependency, API, version,
convention, integration, security boundary, or concurrency assumption.
- Classify claims as
confirmed, uncertain, or refuted.
- Use references/mirage-patterns.md.
Phase 3 — Cold-Start Executability
- Simulate a fresh executor starting the first phases with only the plan and repository.
- Stop at the first real blocker.
- Require concrete inputs, outputs, commands, test specifics, inter-phase contracts, and
recovery for destructive work.
Verdict
APPROVED: all required phases pass and implementation may start.
NEEDS_REVISION: the design is viable but specific plan defects must be fixed.
REJECTED: the scope or architecture is not safely deliverable as written.
- Include
failure_classification: fixable, needs_replan, or escalate for non-approval.
- Write a compact verdict to
plans/artifacts/<task-slug>/verify-verdict.md.
- Do not start implementation until the verdict is
APPROVED.
Native Host Boundary
- Do not spawn plugin verifier agents.
- If the user explicitly wants an isolated second opinion, native host review or an
explicitly requested native subagent can supplement this inline pass. In Codex,
/review
is the built-in review command.
- The host owns approvals, sandboxing, retries, and subagent lifecycle.
References
references/adversarial-framing.md
references/verify-phases.md
references/mirage-patterns.md
1---2name: controlflow-verify3description: Use after a ControlFlow plan is saved and before implementation. Runs tier-gated adversarial verification inline: structural audit, assumption/mirage detection, and cold-start executability simulation.4---5
6# ControlFlow Verify
7
8## Overview
9
10Verify a saved plan before implementation. The checks run inline in the current host
11context with zero subagents shipped by the plugin. This skill combines the useful parts of the former
12plan-audit, assumption-verifier, and executability-verifier workflows without reproducing
13Codex subagent orchestration.
14
15Select the skill explicitly. In Codex, invoke it with `$controlflow-verify`.
16
17## Input and Contract
18
19- Read the plan from disk; do not verify a chat copy.
20- If the active repository provides `schemas/planner.plan.schema.json` and
21 `plans/templates/plan-document-template.md`, use them.
22- Otherwise use `../controlflow-plan/references/plan-format.md`.
23
24## Tier Gating
25
26| Tier | Verification |
27| --- | --- |
28| `TRIVIAL` | Skip unless explicitly requested |
29| `SMALL` | Phase 1 |
30| `MEDIUM` | Phases 1–2 |
31| `LARGE` | Phases 1–3 |
32
33Any unresolved applicable `HIGH` semantic risk requires all three phases.
34
35## Phase 1 — Structural Audit
36
37- Check the header, section order, lifecycle headings, all seven semantic-risk rows, phase
38 shape, diagrams, exact commands, measurable acceptance criteria, and rollback guidance.
39- Verify referenced paths and tests against the repository.
40- Apply the Minimum Viable Change Ladder before accepting new abstractions, dependencies,
41 or generated surfaces.
42
43## Phase 2 — Assumption and Mirage Check
44
45- Try to refute each factual claim that names a file, symbol, dependency, API, version,
46 convention, integration, security boundary, or concurrency assumption.
47- Classify claims as `confirmed`, `uncertain`, or `refuted`.
48- Use [references/mirage-patterns.md](references/mirage-patterns.md).
49
50## Phase 3 — Cold-Start Executability
51
52- Simulate a fresh executor starting the first phases with only the plan and repository.
53- Stop at the first real blocker.
54- Require concrete inputs, outputs, commands, test specifics, inter-phase contracts, and
55 recovery for destructive work.
56
57## Verdict
58
59- `APPROVED`: all required phases pass and implementation may start.
60- `NEEDS_REVISION`: the design is viable but specific plan defects must be fixed.
61- `REJECTED`: the scope or architecture is not safely deliverable as written.
62- Include `failure_classification: fixable`, `needs_replan`, or `escalate` for non-approval.
63- Write a compact verdict to `plans/artifacts/<task-slug>/verify-verdict.md`.
64- Do not start implementation until the verdict is `APPROVED`.
65
66## Native Host Boundary
67
68- Do not spawn plugin verifier agents.
69- If the user explicitly wants an isolated second opinion, native host review or an
70 explicitly requested native subagent can supplement this inline pass. In Codex, `/review`
71 is the built-in review command.
72- The host owns approvals, sandboxing, retries, and subagent lifecycle.
73
74## References
75
76- `references/adversarial-framing.md`
77- `references/verify-phases.md`
78- `references/mirage-patterns.md`