controlflow-speclisted

# ControlFlow Spec ## Overview Capture a short, durable specification before `$controlflow-planning`. The spec records the outcome, exclusions, success proof, constraints, and unresolved questions so planning does not infer requirements from loose chat context. ## When to Use Use `$controlflow-spec` before `$controlflow-planning` when: - work is `SMALL`, `MEDIUM`, or `LARGE` and no accepted spec exists - acceptance criteria, boundaries, constraints, risks, or success metrics are still implied - the work crosses multiple files, plugin surfaces, schemas, agents, or documentation paths - planning would require Codex to invent priorities, exclusions, or verification gates Skip this skill for `TRIVIAL` fixes where the expected behavior and verification command are already explicit. ## Workflow 1. Restate the requested outcome in one or two sentences. 2. Ask one clarification round only for requirements that would change scope, acceptance, constraints, or risk handling. 3. Save a Markdown spec artifact, usually at `plans/artifacts/<task-slug>/spec.md`, unless the user gives another path. 4. Keep the spec focused on requirements and proof of completion; do not decompose implementation phases. 5. Hand off to `$controlflow-planning` with `spec_path` and intended `plan_path`. ## Spec Capture Template ```markdown # Spec: <task name> ## Objective <What outcome is needed and why it matters.> ## In-Scope <Files, workflows, behaviors, or artifacts that planning may include.> ##