controlflow-verify

name	controlflow-verify
description	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.

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