Planning

Embedded: planning is plan adapter + implementer dispatcher only. Harness drives one round per task:

harness round N (for task N):
  propose:  planning dispatches implementer
  verify:   harness runs verification gate (/critique)
  evaluate: harness decides keep/discard
  record:   harness writes state.jsonl

Implementation Protocol

Each task carries an implementation protocol passed to implementer:

• tdd_required -- default for features, bug fixes, refactors, behavior changes
• tdd_preferred -- test-first when practical, justified fallback allowed
• direct -- config-only, docs-only, generated code, or similar non-TDD work

Default tdd_required when unsure. For tdd_required tasks, implementer must provide RED/GREEN evidence.

When task involves mocks, test doubles, or test-only seams, read references/testing-anti-patterns.md and fold guidance into implementer prompt.

Dispatch Model

Standalone

• Implementer and review gates: foreground child contexts, consumed sequentially.
• Review via /critique.
• Orchestration stays in controller. Child workers do not invoke /fanout or /critique.

Embedded (in /harness)

• Planning only dispatches implementer child context.
• Harness owns /critique gates. Planning does not invoke /critique.

Size Gate

• Multiple independent or cross-file tasks needing staged verification: use this skill.
• Single low-risk task (one-file fix, obvious local change): stay local.
• If coordination overhead exceeds implementation effort: too heavy.
• Once chosen, keep full gate: implement -> quality review. No shortcuts.

The Process (Standalone)

In embedded mode, harness drives round loop and runs verification gates; planning only provides implementer dispatch.

digraph process {
    rankdir=TB;
    subgraph cluster_per_task {
        label="Per Task";
        "Launch implementer (./implementer-prompt.md)" [shape=box];
        "Questions?" [shape=diamond];
        "Answer, re-launch" [shape=box];
        "Implementer implements, tests, commits" [shape=box];
        "/critique" [shape=box];
        "Review pass?" [shape=diamond];
        "Fix issues" [shape=box];
        "Mark task complete" [shape=box];
    }
    "Normalize input into task manifest" [shape=box];
    "More tasks?" [shape=diamond];
    "Done" [shape=box style=filled fillcolor=lightgreen];
    "Normalize input into task manifest" -> "Launch implementer (./implementer-prompt.md)";
    "Launch implementer (./implementer-prompt.md)" -> "Questions?";
    "Questions?" -> "Answer, re-launch" [label="yes"];
    "Answer, re-launch" -> "Launch implementer (./implementer-prompt.md)";
    "Questions?" -> "Implementer implements, tests, commits" [label="no"];
    "Implementer implements, tests, commits" -> "/critique";
    "/critique" -> "Review pass?";
    "Review pass?" -> "Fix issues" [label="fail"];
    "Fix issues" -> "/critique" [label="re-review"];
    "Review pass?" -> "Mark task complete" [label="pass"];
    "Mark task complete" -> "More tasks?";
    "More tasks?" -> "Launch implementer (./implementer-prompt.md)" [label="yes"];
    "More tasks?" -> "Done" [label="no"];
}

Input Normalization

Accepts tasks from multiple sources:

• Plan file path (reads and extracts tasks)
• Inline task list (from harness or caller)
• Existing task manifest (resume)

All inputs normalized into canonical task manifest: