# Conductor

> Explicitly selected worker orchestration for an approved plan or outcome: the parent directs, integrates, and reviews while delegated workers implement. Use when the user chooses $conductor or binding task instructions require it. An ordinary request to finish work or implement a plan does not select a worker fleet.

- Skill: `aelaguiz/conductor` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add aelaguiz/conductor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aelaguiz/conductor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: aelaguiz (https://skillmd.com/u/aelaguiz)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/aelaguiz/conductor

---


# Conductor

Use this workflow only after explicit selection as `$conductor` or a
binding task instruction requiring it. Intake spans a spectrum —
a finished plan document, a partial plan, or a described outcome. What already
exists on disk decides how much shaping happens first; the execution
machinery is identical for all three.

The role economy is the point. The parent spends its scarce context on
judgment, not keystrokes: it reads the plan once, designs well-sized slices,
delegates implementation through transport selected under the shared agent
policy, and spends its tokens on evidence-based review. Workers implement,
repair, and run proof. The send-back loop — resume the exact worker with batched
audit findings until the slice contract is true in code — is what makes
delegated workers safe.

This is a prompt-first orchestration skill. It ships no runner, controller,
state machine, or script. The parent agent is the orchestrator; the conductor
log beside the plan is its durable memory.

## North Stars

- A plan or outcome goes in; verified, reviewed, contract-faithful code comes
  out.
- Parent tokens go to plan understanding, slice design, cynical audit
  judgment, and first-hand verification of finished work products. Fleet
  tokens go to investigation, implementation, repair, proof runs, and heavy
  review reading — on a selected worker profile, whichever lane carries it. A
  native child inherits the parent's model unless the dispatch pins
  its model and thinking level; a pinned child bills its own. Pin the profile
  or take the external lane, and never route bulk work to an unpinned native
  child.
- The parent is the scope judge. Workers are genuinely smart but
  over-scope and over-iterate; the parent trims every proposal to the
  smallest sufficient solution and holds the approved boundary against
  expansion pressure from any direction.
- Chunk size balances two failure modes: micro-tasks turn the parent into a
  slow programmer with extra round-trips; mega-tasks produce unreviewable
  diffs. Default one plan phase per worker.
- Awareness without burn: a size-scoped background heartbeat on every slice
  proves liveness and catches a wedge early with cheap signals. Never tail
  raw worker event streams.
- Every worker return starts NOT ACCEPTED. Worker output — status, summary,
  quoted proof, labels, conclusions — is a claims manifest to falsify against
  repo truth, never a report to consume. The authority is what the conductor
  verifies first-hand: current code, and the work products it has personally
  loaded and checked.

## Use When

- The user names an existing plan doc and wants the whole thing (or a phase
  range) implemented by delegated phase workers with the parent as reviewer.
- The user has a described outcome or a partial plan — not a finished plan —
  and wants the parent to decompose it, using worker research where useful,
  approve a scope boundary once, and then conduct execution without a
  separate planning invocation.
- The user wants the parent to preserve architectural and review context while
  capable workers own implementation and proof inside plan-authorized slices.
- The plan is arch-step, miniarch-step, arch-mini-plan, or lilarch shaped — or
  any format with recoverable requirements, phases, and done-ness.
- The user wants implementation velocity plus cost control on one long-running
  plan execution.
- The user explicitly invokes `conductor terra` or asks for their
  standard Terra delivery path: dedicated worktree, Terra xhigh execution,
  three new clean external cynical reviews, PR publication, and PR
  follow-through.

## Do Not Use When

- The plan artifact itself is the deliverable, or the work needs full
  architecture ceremony (research, deep-dives, staged review gates) before
  any execution. Use `$arch-step`, `$arch-mini-plan`, or `$lilarch`, then
  hand the finished plan back here.
- The goal is clear but no definable done-state exists even in principle —
  open-ended optimization or metric improvement. Use native goal mode; the
  conductor requires observable done-ness before dispatch.
- The user wants the parent to implement the plan itself rather than remain a
  non-implementing architect. Use `$plan-implement`.
- The user wants one concrete external delegated task rather than plan-sized
  orchestration. Use `$agent-delegate`; dispatch an ordinary same-host task
  directly through the active host's native child system.
- The user wants a plan audited, not implemented. Use `$plan-audit`.
- The work is a multi-plan epic decomposition. Use `$arch-epic`.
- The workflow is a strict ordered process from another repo's doctrine. Use
  `$stepwise`.
- The user wants a read-only second opinion. Use `$fresh-consult`.

## Non-Negotiables

- The conducted artifact — the finished plan, or the approved outcome map
  when shaping produced one — is the single source of truth, and "the plan"
  below always means that artifact. The conductor log
  (`<PLAN_STEM>_CONDUCTOR_LOG.md` beside it) is schedule, evidence, and
  resume state — never a second plan.
- Whole plan is the default boundary; honor an explicit phase range exactly.
- Apply `../_shared/agent-orchestration-policy.md` at every worker and
  reviewer dispatch, and apply `$prompt-authoring` to every actual populated
  first brief or materially reframed follow-up. Resolve the worker profile
  before the lane: model, thinking level, durability, isolation, receipts.
  The fleet is that profile — explicitly selected — and it applies to every
  role: phase workers, research workers, verification workers, any cynical
  review the user asked for, and the cold verifier. Take the native lane when
  the profile is reachable in this host's child catalog, pinnable in both
  model and thinking level, durable across this run's resume pattern, and
  unblocked by any external-only need. Otherwise take `$agent-delegate` and
  name which test failed — cross-provider reach the host cannot give, `aim`
  usage-limit rotation, a session that must outlive the parent process,
  required run receipts, concurrency past the native cap, or isolation the
  host cannot enforce. An unpinned native child runs the conductor's own
  profile, so pin the selected model and effort before assigning bulk reading. Honor explicit user choices in both directions.
- Model and thinking level are first-class worker values on both lanes, drawn
  from one vocabulary, and the user normally supplies them. A Codex worker
  with no named model defaults to `gpt-6-astra`, and an omitted level on that
  Astra worker defaults to `xhigh`; a Kimi worker with omitted model and level
  defaults to `kimi-code/k3` at `max`. Accept `astra`, `luna`, and `terra` as
  `gpt-6-astra`, `gpt-5.6-luna`, and `gpt-5.6-terra`. Ask one consolidated
  question only for load-bearing missing values. Provider routing remains:
  Codex runs GPT/GBT/OpenAI ids and Fugu profiles, Claude Code runs supported
  Claude models, Cursor Agent runs `composer-2.5-fast`, natural Grok wording
  resolves to `grok-4.6`, and Kimi runs `kimi-code/k3` with an omitted-level
  default of `max`. Explicit legacy Grok ids remain exact and discovery-gated.
  Announce the resolved model, thinking level, and lane before the first
  launch, and never change any of the three silently mid-run.
- When intake is a described outcome or a partial plan, run the executive
  shaping stage per `references/shaping-and-outcome-map.md` before any plan
  intake: worker research as evidence, a parent-owned trim to the smallest
  sufficient solution, an outcome map written beside the work, and one user
  approval of the scope boundary — skippable only by an explicit user
  `full-auto` grant. Research workers propose; they never decide, and no
  worker implements anything during shaping.
- Read the plan once, end to end, at intake. If it yields no observable
  done-ness anywhere — no requirements, checklists, exit criteria, or
  verification obligations — stop before dispatching any worker and report
  what is missing instead of inventing scope. The readiness gate applies to
  a shaped outcome map exactly as to a finished plan and is never waived;
  shaping happens before the gate, never around it.
- Apply `../_shared/scope-and-convergence.md`. Intake must recover the
  human-authorized outcome and approval anchors, smallest sufficient solution,
  initial minimal convergence closure, scope sign-off boundary, enough proof,
  do-not-build boundary, and accepted residual risk. Observable checklists are
  insufficient when that provenance is missing, contradictory, or obviously
  overbroad. Do not dispatch an unapproved or scope-laundered plan. When
  shaping produced the outcome map, the recorded scope approval (or the
  explicit `full-auto` grant) is the human authorization anchor and the
  sign-off.
- The initial architecture window is already closed when conductor execution
  begins. Workers, the conductor, warm audits, cold verification, cynical
  reviews, PR feedback, and repeated findings cannot add to the approved closure.
  A newly discovered same-contract adjacent path requires a human decision.
- The conductor never edits source code. It edits only coordination artifacts
  and plan completion annotations. It never edits the plan's requirements,
  checklists, or exit criteria to match what was built; scope changes escalate
  to the user.
- Plan completion annotations may record execution truth only. The conductor
  may not edit scope, requirements, or the initial closure to normalize worker
  or reviewer discoveries. Post-approval expansion requires explicit human
  approval and a re-approved plan before dispatch resumes.
- Initial workers are new clean children on the selected lane. Repairs resume
  the exact captured handle through its original transport. Never resume
  "latest" or reuse an unrelated handle. The optional cold verifier and every
  independent review gate start as new clean children on the selected worker
  profile, never on an unpinned native child, because review reading is the
  largest block of bulk tokens in the run.
- Native model, thinking level, and starting context are all explicit at
  dispatch. Codex states `fork_turns` — `"none"` for a clean phase worker or
  critic, a positive count for deliberately bounded chat context, `"all"` only
  when the whole conversation is genuinely required — because omitting it
  currently inherits everything. Claude uses a clean named subagent by default;
  an explicit conversation fork means full inherited conversation and also
  forces the parent's model, while a skill with `context: fork` is an isolated
  clean subagent context. Prime Agent children are always clean, so a
  load-bearing recent decision goes in the brief. Context choice never implies
  permissions, capabilities, or worktree isolation.
- The parent owns decomposition, external fanout, and integration. Confirm
  whether this host actually lets a child fan out before promising it — some
  hosts cap depth so that a child cannot create children at all — then tell
  each worker what it may do, and tell every worker it must not spawn external
  agents itself.
- Chunk default is one plan phase per worker. Split only along owner
  boundaries the plan itself names; merge trivial adjacent phases that share
  one design intent; when unsure, chunk bigger. Never one file per worker,
  never micro-tasks, never two workers into one unsettled design decision.
- Parallelize only dependency-ready slices on disjoint surfaces. Serial
  execution is correct when the plan is serial.
- Arm a size-scoped liveness monitor on every dispatched slice: heartbeat
  floor five minutes, ceiling thirty, scaled to the slice's expected
  duration. Each beat emits one compact liveness-and-progress line, relayed to
  the user as a brief check-in, plus a wedge alert when the worker dies, stalls
  with no progress across beats, or overruns its ceiling. This is standing
  practice on every dispatch, resume, and respawn — never wait for the user to
  ask for it, and never clear it after a slice and forget to re-arm the next.
  Cheap signals only; never stream an external lane's `events.jsonl` into
  parent context during normal operation. Quiet with a live heartbeat is not
  stuck; act on evidence, not silence.
- Audit with inverted burden of proof before accepting any slice: enumerate
  the worker's claims, falsify them against git and current code, trace the
  authority path beyond the diff (side doors live in files the diff did not
  touch), and apply the integrity, architecture, and cruft lens groups from
  `references/audit-and-send-back.md`. Worker-quoted verification is a claim;
  decisive proof is independently reproduced by a different clean fleet
  worker before acceptance. A worker rebuttal never closes a finding without
  conductor-verified evidence. A clean pass must record which lying-modes
  were checked.
- Verify the work product itself before believing any completion claim, and
  treat that verification as sanctioned first-class parent spend — loading
  the artifact is never token waste. Existence is not evidence, and neither
  is plausible shape. A screenshot is accepted only after the conductor has
  viewed it and confirmed it shows the claimed state — not a blank page,
  error screen, wrong screen, or stale build; a spreadsheet or data model
  only after the conductor opened it and checked the math — representative
  totals spot-recomputed, formulas traced to stated assumptions, key
  numbers tied to their sources; a report only after its assertions were
  checked against current code; a generated file only after it was opened
  and spot-checked against its claimed source. Delegate inspection only for
  an artifact class the conductor genuinely cannot render, and require
  extracted evidence back — values, quotes, described screen content —
  never a verdict. The implementing worker's description of its own
  artifact never counts as inspection.
- Never adopt a worker's analytical conclusion at face value. A conclusion
  the conductor acts on, relays, or closes a finding with must carry
  anchors the conductor has verified; an unanchored conclusion goes back
  for evidence as a hypothesis, not forward as a fact.
- Separate factual validity from scope authority for every finding. Record one
  shared scope disposition. Only `authorized` and
  `approved-convergence-required` become send-backs. `new-scope-needs-human` is
  escalated, `out-of-scope` stays an observation, and
  `unauthorized-built-scope` requires subtraction unless a human ratifies and
  re-approves it. Repetition never changes the disposition.
- Batch all accepted findings into one resume prompt per repair round. Caps:
  3 send-backs per worker handle, then 1 new clean respawn with a sharpened
  brief, then escalate the slice and continue independent work. The same finding surviving
  two consecutive send-backs marks the worker unhealthy immediately. Two
  consecutive malformed or failed child runs on one slice escalate it.
- An external Codex worker that dies on a hard usage limit is continued, not
  replaced: rotate accounts and resume the exact captured session per
  `$agent-delegate`'s usage-limit continuity and
  `../_shared/aim-rotation.md`. Rotation is not a send-back, respawn, or
  failed run for cap purposes; record it in the conductor log.
- Delegate all proof runs (tests, builds, generators, simulators) to
  workers; decisive proof counts only when a different clean worker on the
  fleet profile reproduced it. The parent runs read-only inspection, which
  includes personally loading and reading work-product artifacts — that
  verification belongs to the parent and is never delegated for economy.
  Reuse fresh passing proof; rerun only on a real invalidator.
- The parent commits local checkpoints after accepted slices and meaningful
  batches. During the conductor stage it never pushes or opens PRs. Delivery
  past that boundary — when the user asked for the work to be published, and
  always under the Terra shortcut — is itself delegated: a dedicated
  delivery worker, a child and never the parent, runs `$pr-authoring` and
  then `$pr-review-followthrough` on the finished branch until CI is green
  and the PR is merge-ready. The parent verifies the outcome first-hand —
  the published PR loaded and read, CI state checked — before closing, and
  never merges or enables auto-merge without a separate user ask. Other
  workers never commit, push, stash, or revert unrelated work; only the
  explicitly assigned delivery worker touches push and PR operations.
- Before phase closure, plan-required proof must be recorded passing. Before
  plan closure, run the final gate: one whole-plan cynical audit sweep —
  which personally loads the plan's end-state work products, a check no
  toggle disables — plus a new clean cold verifier (default on; user may
  disable). The installed `$cynical-code-review`,
  `$cynical-architecture-review`, and `$cynical-cruft-removal` skills are not
  part of that gate. Run them only when the user asks for them, treat what
  they return as advice triaged like any other claim, and let their verdicts
  gate completion only if the user said they should. The Terra shortcut is
  itself such a request and keeps its own three-review gate.
- Record completion the way the plan format already records it (for example
  `Status: COMPLETE` under arch phase headings plus a worklog entry, or
  checkbox ticks). Never hand-edit script-owned `arch_skill:block:*` receipt
  blocks and never write the `plan-audit` sidecar; those belong to their
  owning skills.
- Default wave cap is 25 (one wave = design, dispatch, wait, audit, route),
  user-tunable. When a cap or the readiness gate stops the run, report
  blockers plainly with the log as evidence; escalation is a first-class
  outcome, not a failure.

## First Move

1. If the user explicitly invoked the Terra delivery shortcut, read
   `references/terra-delivery-shortcut.md` and apply its locked execution and
   delivery policy. Do not activate the shortcut merely because an ordinary
   conductor request selected a Terra worker.
2. Read `references/workflow-contract.md`.
3. Place the intake on the spectrum. A finished plan with recoverable
   done-ness continues directly. A described outcome or a partial plan first
   runs the shaping stage — read `references/shaping-and-outcome-map.md`,
   produce the approved outcome map, and continue with that map as the
   conducted artifact.
4. Read `references/plan-intake-and-readiness.md`.
5. Read `../_shared/scope-and-convergence.md`.
6. Resolve the artifact path, boundary (whole plan unless the user named a
   phase range), the worker profile, per-role lane and starting context, max
   parallelism, wave cap, and cold-verifier toggle. The fleet profile defaults
   to Codex `gpt-6-astra` at `xhigh`; a user-named provider swaps the whole
   fleet — Kimi to `kimi-code/k3` at `max`, Grok to `grok-4.6`, Cursor to
   `composer-2.5-fast`, Claude to a supported Claude model. Then pick the lane
   per `references/delegation-and-monitoring.md`: a native child when this host
   can pin that model and thinking level durably, otherwise `$agent-delegate`.
   Ask one consolidated question only for load-bearing missing values. The
   Terra shortcut supplies its own external execution values, so do not ask for
   them.
7. Read the plan once end to end and extract the execution map in context.
8. Before creating or updating the conductor log, inspect `git status` and
   capture the start commit and inherited worktree state. Then write the
   extracted execution map to `<PLAN_STEM>_CONDUCTOR_LOG.md` and record the
   start commit, then apply and record the readiness gate. If the gate passes,
   take an initial or resume checkpoint before launching workers only when the
   inherited worktree already held plan work to preserve (per Git Posture) —
   never an empty checkpoint just to mark intake. Skip it on a concrete safety
   issue such as secrets or clearly unrelated files.
9. Read `references/chunking-and-parallelism.md`, then design and dispatch
   the first wave.

## Workflow

1. If intake is a described outcome or a partial plan, run the shaping stage
   per `references/shaping-and-outcome-map.md`: worker research as evidence,
   parent trim to the smallest sufficient solution, the outcome map written
   beside the work, one scope approval, sign-off. The approved map is the
   conducted artifact everywhere "the plan" appears below.
2. Extract the plan into the conductor log: requirements, non-goals, phases
   with dependency order, per-phase checklist, verification, exit criteria,
   and cleanup/delete obligations — as anchors into the plan, not copied
   prose.
3. Each wave: pick the next dependency-ready slice or slices, sized by the
   chunking doctrine.
4. Dispatch each slice as a new clean child on the selected lane using the
   worker prompt contract — a native child pinned to the fleet model and
   thinking level, or a fresh-resumable `$agent-delegate` session. Record the
   lane, model, thinking level, starting context, exact handle, and any
   external run directory in the log.
5. Arm the slice's size-scoped watchdog, then wait patiently per the
   monitoring doctrine. A hard usage-limit death is continued by rotate and
   exact-session resume, not by replacement.
6. On return, audit per `references/audit-and-send-back.md`: enumerate the
   claims to falsify, check them against git, trace the authority path
   beyond the diff, personally load and verify every claimed work product,
   falsify analytical conclusions at their anchors, apply the three lens
   groups, and require decisive proof to be independently reproduced. Judge
   factual validity separately from scope disposition. Only factually valid
   findings already inside the approved contract become repair work.
7. Route: batch accepted findings into one resume prompt and send the session
   back; or accept the slice with evidence anchors and commit a checkpoint;
   or respawn fresh; or escalate and continue independent slices.
8. When a phase's slices are accepted, delegate the phase's plan-required
   verification, record proof in the log, and record phase completion in the
   plan's own format.
9. Repeat until the execution map is clean or a hard stop triggers.
10. Run the final gate: whole-plan cynical audit sweep, then the fleet cold
   verifier unless disabled. Triage and repair findings through the same
   send-back machinery. Run a cynical review skill only when the user asked
   for it — each requested one as its own clean session on the fleet profile,
   never an unpinned native child — and treat its return as advice, not a
   gate. When the change set is large or structural, or the completion story
   is one you could not fully verify, say so in the final report and offer the
   reviews instead of running them unasked. Under the Terra shortcut, step 11
   owns the three reviews. Give every final reviewer the plan path, human baseline
   anchors, approval entries, approved initial closure, and approval anchor. Their
   findings use the same scope triage and cannot expand the plan.
11. If the Terra delivery shortcut is active, run its stronger delivery gate:
    all three cynical reviews in independent new clean external Terra
    sessions, with accepted findings repaired and re-reviewed.
12. When the user asked for the work to be published (always true under
    Terra), dispatch a dedicated delivery worker — a child, never the
    parent — to run `$pr-authoring` and then `$pr-review-followthrough` on
    the finished branch until CI is green and the PR is merge-ready. Track
    it with the normal heartbeat doctrine, then verify the result
    first-hand: load the published PR, read what was posted, and check CI
    state. Give the user the Delivery Report when the PR goes up and again,
    refreshed, at merge-ready.
13. Write the final report, commit the final checkpoint, and stop at the
    requested boundary.

## Progress Updates

After each wave and whenever the user asks for status, give one compact
Markdown table: slice, goal, worker/handle, state, attempts, and current
blocker or next action. Refresh from the conductor log and repo state before
answering. Keep chat lean; detail lives in the log.

## Delivery Report

When the delivery worker publishes the PR, and again when follow-through
reaches merge-ready, give the user the same at-a-glance report, refreshed
from the conductor log and first-hand-verified PR state — never from memory
or the worker's narrative:

| Field | Value |
|---|---|
| PR | \<url\> (\<branch\> → \<base\>) |
| State | published \| merge-ready |
| CI | passing \| failing (name the check) \| pending |

Then four short bullet sections:

- **Accomplished** — what shipped, stated against the plan's requirements
  with their anchors.
- **Tested** — the decisive proof: each check, its scope, its result, and
  who ran it (from the proof ledger's `Ran by`).
- **Reviewed** — which audits, requested cynical reviews, and verifiers ran,
  their verdicts, and finding counts: accepted / repaired / rejected.
- **Issues** — escalations, notable send-backs, usage-limit rotations,
  deferred items, and anything the user should know; `none` when true.

The merge-ready report updates the publication report; it does not retell
the run story.

## Output

Report compactly:

- conducted artifact path (plan or outcome map), boundary, and conductor log
  path
- worker policy (transport, starting context, and any external
  runtime/model/effort) and max parallelism
- per-wave status table
- slices accepted, sent back, respawned, escalated, or deferred, with attempt
  counts
- proof run, reused, or still owed, with the invalidator reasoning
- findings triage summary and any rejected-finding evidence
- scope-integrity summary: contract anchor, human decisions requested, scope
  cycles found, and unauthorized work subtracted
- commits made, files changed, and plan completion annotations written
- escalations with the specific user decision each one needs
- the Delivery Report when delivery ran (PR, CI, accomplished / tested /
  reviewed / issues)
- next action or final verdict with evidence

## Reference Map

- `references/shaping-and-outcome-map.md` - executive shaping stage for
  outcome or partial-plan intake, and the outcome map contract
- `references/workflow-contract.md` - conductor lifecycle, roles, git posture,
  and stop discipline
- `references/plan-intake-and-readiness.md` - format-agnostic extraction,
  readiness gate, and the arch-format fast path
- `references/chunking-and-parallelism.md` - slice sizing litmus tests and
  parallel launch judgment
- `references/delegation-and-monitoring.md` - transport selection, native and
  external continuation, patient monitoring, and the parent token economy
- `references/audit-and-send-back.md` - cynical audit lenses, finding triage,
  send-back caps, escalation, and the final gate
- `references/terra-delivery-shortcut.md` - explicit standard Terra worktree,
  implementation, independent review, repair, PR, and follow-through path
- `references/worker-prompt-contract.md` - worker slice prompt skeleton,
  required footer, and send-back prompt shape
- `references/conductor-log-contract.md` - conductor log layout, status
  enums, proof ledger, and exit probe