Conductor

One skill, three modes, one shared artifact: a repo-local spec folder.

• plan — design the work and write the dispatch task list.
• exec — run the task list, dispatching to subagents or external executors.
• verify — judge the result against acceptance, fresh-eyed.

Conductor orchestrates; it composes other skills rather than reimplementing them: specs/CLAUDE.md for PRODUCT.md/TECH.md, grill-me to stress-test the design, and testing for the verify strategy. It dispatches impl/test/review work to a separate clean-context executor chosen by each task's backend — opencode (DeepSeek), cursor (Composer), omp (Oh My Pi CLI), codex (codex plugin in Claude Code, codex exec CLI elsewhere), or claude.

Default Roles

Claude (the host CLI) plans and orchestrates. Codex executes impl/test work and reviews (review tasks and verify) via the codex plugin in Claude Code, the codex exec CLI elsewhere; conductor can also dispatch to opencode (DeepSeek 4 Pro), cursor (Composer 2.5), and omp (Oh My Pi CLI) per a task's backend — separate process, clean context, fresh eyes. Claude executes directly for host-context work or as the last resort.

Mode Selection

Mode is explicit. The user passes it: /conductor plan|exec|verify.

If the mode is absent, infer a suggestion from spec state and confirm before acting:

• no spec folder → suggest plan
• spec with pending tasks → suggest exec
• all tasks done → suggest verify

Never act on inference for ambiguous states: failed tasks, a partially written spec, a stale HANDOFF.md, changed TECH.md tests, or a dirty worktree. Ask the user which mode they mean.

Spec Folder

Repo-local, following specs/CLAUDE.md:

specs/<ticket-id>/                   # when tied to an issue/ticket
specs/YYYYMMDD-HHMM-<kebab-title>/   # otherwise
├── PRODUCT.md    # intent + ## Acceptance with stable VAL-* ids   (specs/CLAUDE.md)
├── TECH.md       # approach + ## Tests + verification commands     (specs/CLAUDE.md)
├── FINDINGS.md   # research journal + append-only ## Execution Log
├── TASKS.md      # execution marker + TOON dispatch block + status
├── HANDOFF.md    # final rollup, written by verify
└── runs/<task-id>/   # evidence, git-ignored (impl/test: summary + diff; review: review.log)

There is no separate validation-contract.md or progress.md. Their functions live on:

• definition of done → PRODUCT.md ## Acceptance with stable VAL-* ids; each behavior-claiming task carries contract_refs.
• current task state (canonical) → TASKS.md TOON status + result; resume reads these.
• status history (canonical, append-only) → FINDINGS.md ## Execution Log; it is the status-regression baseline, not a mere projection. A TOON-vs-log disagreement is a ledger error (regression), valid only with a replanned log entry — not auto-won by TOON.
• projections (lose to TOON on conflict) → runs/<task-id>/ (git-ignored artifacts), HANDOFF.md, the dependency view, the Mermaid graph, and the Claude Code native Task mirror.

Operating Principles

• Parallelism: design parallel batches from independent work, not from wishful concurrency.
• Drift Control: pin every task to acceptance ids, repo facts, or explicit assumptions; stop when evidence conflicts.
• Speed: remove serial waits unless a dependency is real.
• Token Efficiency: write short task descriptions and point to files instead of pasting large context.
• Granularity: create right-sized tasks with one clear outcome, one owner, and one verification path.

Modes

Read only the reference for the active mode:

• plan → references/plan.md
• exec → references/exec.md
• verify → references/verify.md

Templates: references/tasks-template.md, references/findings-template.md, references/handoff-template.md.

When Not to Use

Ad-hoc or trivial work (a single edit, a quick fix) skips conductor — use the default plan mode of the host CLI. Conductor is for serious multi-step dev that benefits from a durable spec folder.