• User runs

  /delegate

  command
• Implementation plan is ready with extractable tasks
• User wants to parallelize work across subagents

workflowType === "oneshot"

@skills/oneshot/SKILL.md

• No shared state assumptions. Every subagent prompt must contain the full task description, file paths, TDD requirements, and acceptance criteria. Never say "see the plan" or "as discussed earlier."
• No cross-agent references. Subagent A must not depend on output from Subagent B unless explicitly sequenced with a dependency edge in the plan.
• Isolated worktrees. Each subagent operates in its own

  git worktree

  . Parallel agents in the same worktree will corrupt branch state.

references/rationalization-refutation.md

1. Task complexity:

   exarchos_orchestrate({ action: "runbook", id: "task-classification" })

   to get the cognitive complexity classification tree. Low-complexity tasks can use the scaffolder agent spec for faster execution.
2. Dispatch strategy:

   exarchos_orchestrate({ action: "runbook", id: "dispatch-decision" })

   for dispatch strategy (parallel vs sequential, team sizing, isolation mode).

prepare_delegation

Authoritative spec: the canonical list of preconditions, blockers, and arguments for

prepare_delegation

lives in the runtime — query it with

exarchos_orchestrate({ action: "describe", actions: ["prepare_delegation"] })

if anything in this skill drifts from observed behavior. Treat the runtime

describe

output as the source of truth.

exarchos_orchestrate({
  action: "prepare_delegation",
  featureId: "<featureId>",
  planPath: "docs/specs/<the-decomposition-spec>.md",
  tasks: [{ id: "task-001", title: "...", modules: [...] }, ...]
})

planPath

prepare_delegation

**Risk Tier:**

**Boundary Touching:**

planPath

riskTier

boundaryTouching

high

riskTier

boundaryTouching

tasks[]

npm install

setup_worktree

.worktrees/<taskId>-<taskName>

1. State validation — verifies workflow state is in

   delegate

   phase, plan exists, plan approved
2. Quality signal assembly — queries

   code_quality

   view; if

   gatePassRate < 0.80

   , returns quality hints to embed in prompts. Emits

   gate.executed('plan-coverage')

   on success (no pre-query needed)
3. Benchmark detection — sets

   verification.hasBenchmarks

   if any task has benchmark criteria
4. Readiness verdict — returns

   { ready: true, worktrees: [...], qualityHints: [...] }

   (the

   worktrees

   array reports the expected paths, not created ones) or

   { ready: false, reason: "..." }

blocked: true

reason: "current-branch-protected"

hint

ready: false

ready: true

worktrees

qualityHints

nativeIsolation: true

prepare_delegation

ready: true

worktrees.ready: 0

worktrees.expected > 0

.worktrees/

pwd

git worktree add -b <task-branch> .worktrees/<taskId>-<taskName> <integration-tip>

<taskId>-<taskName>

setup_worktree

• Full task description (paste inline; never reference external files)
• The

  **Risk Tier:**

  /

  **Boundary Touching:**

  stamps are lifted automatically when you pass

  planPath

  (above) — you do NOT need to re-transcribe them into

  tasks[]

  ; pass them explicitly only to override the plan for a specific task
• Files to create/modify as worktree-relative paths rooted inside the worktree (e.g.

  src/foo.ts

  ) — never an absolute parent-repo path, and never a

  ..

  sequence that escapes the worktree root. Either form resolves outside the agent's worktree cwd and silently writes into the main worktree. This is the platform-agnostic line of defense — it must hold on every runtime.
• Test file paths (worktree-relative) and expected test names
• Dependencies on other tasks (for sequencing)
• Property-based testing flag (

  testingStrategy.propertyTests

  )

references/worked-example.md

1. Full task description (requirements, acceptance criteria)
2. Working directory (worktree path from Step 1)
3. File paths to create/modify and test file paths
4. Quality hints (if any)
5. PBT flag when

   propertyTests: true

1. Fill the implementer prompt template with task-specific details
2. Set the

   Working Directory

   to the worktree path from Step 1
3. Include quality hints (if any) in the Quality Signals section
4. Include PBT section from

   references/pbt-patterns.md

   when

   propertyTests: true

5. Include testing patterns from

   references/testing-patterns.md

task --agent implementer 'Implement task-001: [title]: Task-specific context: requirements, file paths, acceptance criteria'

Note: Include the full implementer prompt template from

references/implementer-prompt.md

in the dispatch payload so the spawned agent has a self-contained context — runtimes that pre-bind the implementer prompt to a named agent will discard the redundant content automatically.

references/parallel-strategy.md

check_integration_suite

post_delegation_check

1. task_complete

   is the terminal step of the task-completion runbook. No blocking gate may run after it — a task that is marked complete has already passed every gate that could block it.

2. check_integration_suite

   is a wave-boundary backstop, not a per-task gate. It runs exactly once per wave, after the merges, matching its own action description. Per-task cascade risk is covered by the task's own scoped gates.

inline reply from task --agent (no separate collection API)

Runbook: For each completed task, execute the task-completion runbook:

exarchos_orchestrate({ action: "runbook", id: "task-completion" })

Execute the returned steps in order. Stop on gate failure. If the runbook action is unavailable, use

describe

to retrieve gate schemas and run manually:

exarchos_orchestrate({ action: "describe", actions: ["check_test_adequacy", "check_static_analysis", "task_complete"] })

1. Extract provenance from subagent report — parse the subagent's completion output and extract structured provenance fields (

   implements

   ,

   tests

   ,

   files

   ). These fields are reported by the subagent following the Provenance Reporting section of the implementer prompt.
2. Verify worktree state — confirm each worktree has clean

   git status

   and passing tests
3. Run blocking gates — the

   task-completion

   runbook (referenced above) defines the exact gate sequence (test adequacy, static analysis, then task_complete). On any gate failure, keep the task in-progress and report findings. All gate handlers auto-emit

   gate.executed

   events, so manual

   exarchos_event

   calls are not needed.
4. Pass provenance in task completion — when marking a task complete, pass the extracted provenance fields in the

   result

   parameter so they flow into the

   task.completed

   event:

exarchos_orchestrate({
  action: "task_complete",
  taskId: "<taskId>",
  streamId: "<featureId>",
  result: {
    summary: "<task summary>",
    implements: ["DR-1", "DR-3"],
    tests: [{ name: "testName", file: "path/to/test.ts" }],
    files: ["path/to/impl.ts", "path/to/test.ts"]
  }
})

1. Update workflow state — set each passing

   tasks[].status

   to

   "complete"

   via

   exarchos_workflow update

2. Delegation completion gate (D4, advisory) — after ALL tasks pass, run an operational resilience check on the full branch diff before transitioning to review:

exarchos_orchestrate({
  action: "check_operational_resilience",
  featureId: "<featureId>",
  repoRoot: ".",
  baseBranch: "main"
})

1. Schema sync — if any task modified API files (

   *Endpoints.cs

   ,

   Models/*.cs

   ), run

   npm run sync:schemas

1. Read the failure output from the runtime's result-collection primitive (

   inline reply from task --agent (no separate collection API)

   )
2. Diagnose root cause — do NOT trust the implementer's self-assessment (see R3 adversarial posture)
3. Fix the task using the fixer flow below
4. Run the

   task-fix

   runbook gate chain after the fix completes

references/worked-example.md

references/fixer-prompt.md

--fixes <state-file-path>

.reviews.<taskId>.specReview

.reviews.<taskId>.qualityReview

references/fix-mode.md

Deprecated:

--pr-fixes

has been superseded by

/exarchos:shepherd

. Use the shepherd skill for PR feedback workflows.

1. Query workflow state:

   exarchos_workflow get

   with

   fields: ["tasks"]

2. Check active worktrees:

   ls .worktrees/

   and verify branch state
3. Reconcile:

   exarchos_workflow reconcile

   replays the event stream and patches stale task state (CAS-protected)
4. Do NOT re-create branches or re-dispatch agents until confirmed lost

@skills/checkpoint/references/phase-transitions.md

delegate

review

all-tasks-complete

tasks[].status

"complete"

Before transitioning to review: You MUST first update all task statuses to

"complete"

via

exarchos_workflow update

with the tasks array. The phase transition will be rejected by the guard if any task is still pending/in_progress/failed. Update tasks first, then set the phase in a separate call.

git status

1. Capture the rollback SHA before doing anything destructive:
   bash

   git rev-parse <feature-branch> > /tmp/rollback.sha

   Keep this until the merge has been verified. If anything goes wrong,

   git reset --hard "$(cat /tmp/rollback.sha)"

   on the feature branch restores the pre-rebase state. The filename is intentionally branch-name-free so slash-delimited branches like

   feature/dr-6

   don't break the path with embedded

   /

   characters.
2. Rebase the feature branch onto the current integration tip:
   bash

   cd <feature-worktree-path>
   git fetch origin
   git rebase <integration-branch>

   Resolve any conflicts that surface. The conflicts are real — they reflect genuine drift between the two branches, not preflight noise. Do not pass

   --strategy-option=theirs

   blindly; that drops the subagent's work.
3. Re-run the integration merge from the main worktree — through

   serialize_merge

   , which re-composes

   merge_orchestrate

   's ancestry preflight under the single-writer lease:
   typescript

   exarchos_orchestrate({
     action: "serialize_merge",
     featureId: "<featureId>",
     integrationRef: "<integration-branch>",
     sourceBranch: "<feature-branch>",
     strategy: "squash",           // squash | rebase | merge
     taskId: "<taskId>",
     dryRun: false,                // REQUIRED to execute — the action DEFAULTS to dry-run
   })

   serialize_merge

   defaults to a dry-run (preflight only, no lease claimed): omit

   dryRun

   and it reports whether the merge would apply without mutating anything. Pass

   dryRun: false

   to actually claim the single-writer lease and perform the merge. The action is declared shared-mutating, so a read-only caller (a session without write capability) is denied even the apply path; in that case fall back to a local-git merge from the main worktree (

   git merge --squash <feature-branch>

   then commit) and record the equivalent merge state/events yourself, since that merge sits outside the serialized lease.
   The preflight should now pass. Proceed with the orchestrator's normal merge flow. (Re-run raw

   merge_orchestrate

   directly only for a non-integration merge, or as the crash-resumed caller re-presenting its original

   leaseOperationId

   .)

1. Reset the feature branch to the captured rollback SHA:
   bash

   cd <feature-worktree-path>
   git rebase --abort   # if mid-rebase
   git reset --hard "$(cat /tmp/rollback.sha)"

2. Mark the task

   failed

   in workflow state and dispatch a fixer (see the Failure Recovery section above). Do not delete the worktree — the fixer needs the original branch state to diagnose the conflict.
3. Record the incident by emitting a

   merge.aborted

   event with

   reason: "ancestry-rebase-conflict"

   and the failing branch's pre-rebase SHA so the convergence view captures the rollback.

1. Verify all

   tasks[].status === "complete"

   in workflow state
2. Update state:

   exarchos_workflow update

   with

   phase: "review"

3. Invoke:

   [Invoke the exarchos:review skill with args: <plan-path>]