Delegation Skill

Dispatch implementation tasks to subagents with proper context, worktree isolation, and TDD requirements. This skill follows a three-step flow: Prepare, Dispatch, Monitor.

Triggers

Activate this skill when:

User runs
```
/delegate
```
command
Implementation plan is ready with extractable tasks
User wants to parallelize work across subagents

Exception — oneshot workflows skip delegation entirely. The oneshot playbook runs an in-session TDD loop in the main agent's context, with no subagent dispatch or review phase. If

workflowType === "oneshot"

, do not call this skill — see

@skills/oneshot-workflow/SKILL.md

for the lightweight path.

Core Principles

Fresh Context Per Task (MANDATORY)

Each subagent MUST start with a clean, self-contained context. As established in the Anthropic best practices for multi-agent coordination:

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.

Rationalization patterns that violate this principle are catalogued in

references/rationalization-refutation.md

Delegation Modes

The default

subagent

mode dispatches each task using the runtime's spawn primitive:

task

Use the

recommendedModel

from

prepare_delegation

task classifications when available. If no classification exists (e.g., fixer dispatch), omit

model

to inherit the session default.

Pre-Dispatch Schema Discovery

Before dispatching, query decision runbooks to classify the work and select the right strategy:

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.
Dispatch strategy:
```
exarchos_orchestrate({ action: "runbook", id: "dispatch-decision" })
```
for dispatch strategy (parallel vs sequential, team sizing, isolation mode).

Step 1: Prepare

Use the

prepare_delegation

composite action to validate readiness in a single call. This replaces manual script invocations and individual checks.

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.

Step 0 — Pre-emit (required before

prepare_delegation

)

Before calling

prepare_delegation

, the workflow stream must contain a

task.assigned

event for each task. The readiness view counts these events to populate

taskCount

; without them,

prepare_delegation

returns

{ ready: false, blockers: ["no task.assigned events found ..."] }

typescript

exarchos_event({
  action: "batch_append",
  stream: "<featureId>",
  events: tasks.map((t) => ({
    type: "task.assigned",
    data: { taskId: t.id, title: t.title, branch: t.branch },
  })),
})

Step 1 — Prepare (readiness check)

typescript

exarchos_orchestrate({
  action: "prepare_delegation",
  featureId: "<featureId>",
  tasks: [{ id: "task-001", title: "...", modules: [...] }, ...]
})

The composite action performs:

Worktree creation — creates

.worktrees/task-<id>

with

git worktree add

, runs

npm install

State validation — verifies workflow state is in
```
delegate
```
phase, plan exists, plan approved
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)
Benchmark detection — sets
```
verification.hasBenchmarks
```
if any task has benchmark criteria

Readiness verdict — returns

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

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

If
blocked: true
with
reason: "current-branch-protected"
: the response includes a

hint

field (e.g. "checkout the feature/phase branch before dispatching delegation"). Apply the hint, then re-call.

If
ready: false
: Stop. Report the reason to the user. Do not proceed.

If
ready: true
: Extract the

worktrees

paths and

qualityHints

for prompt construction.

Task Extraction

From the implementation plan, extract for each task:

Full task description (paste inline; never reference external files)
Files to create/modify with absolute worktree paths
Test file paths and expected test names
Dependencies on other tasks (for sequencing)
Property-based testing flag (
```
testingStrategy.propertyTests
```
)

For a complete worked example of this flow, see

references/worked-example.md

Step 2: Dispatch

Build subagent prompts using

references/implementer-prompt.md

as the template. Each prompt MUST include the full task context — this is the fresh-context principle in action.

Prompt Construction

On runtimes with native agent definitions:

The implementer agent definition already includes the system prompt, model, isolation, skills, hooks, and memory. The dispatch prompt should contain ONLY task-specific context:

Full task description (requirements, acceptance criteria)
Working directory (worktree path from Step 1)
File paths to create/modify and test file paths
Quality hints (if any)
PBT flag when
```
propertyTests: true
```

Full prompt template (default):

For each task:

Fill the implementer prompt template with task-specific details
Set the
```
Working Directory
```
to the worktree path from Step 1
Include quality hints (if any) in the Quality Signals section

Include PBT section from

references/pbt-patterns.md

when

propertyTests: true

Include testing patterns from
```
references/testing-patterns.md
```

Decision Runbooks

For dispatch strategy decisions, query the decision runbook:

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

This runbook provides structured criteria for parallel vs sequential dispatch, team sizing, and failure escalation.

Parallel Dispatch

Dispatch all independent tasks using the runtime's native spawn primitive in a single message so the dispatches run in parallel.

typescript

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.

For parallel grouping strategy and model selection, see

references/parallel-strategy.md

Step 3: Monitor and Collect

Subagent Monitoring

Collect background task results using the runtime's result-collection primitive (this may be a poll/await per task or inline replies, depending on the runtime):

text

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

After each subagent reports completion:

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_tdd_compliance", "check_static_analysis", "task_complete"] })

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.
Verify worktree state — confirm each worktree has clean
```
git status
```
and passing tests
Run blocking gates — the
```
task-completion
```
runbook (referenced above) defines the exact gate sequence (TDD compliance, 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.
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:

typescript

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"]
  }
})

Update workflow state — set each passing
```
tasks[].status
```
to
```
"complete"
```
via
```
exarchos_workflow set
```
Delegation completion gate (D4, advisory) — after ALL tasks pass, run an operational resilience check on the full branch diff before transitioning to review:

typescript

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

This is advisory — findings are recorded for the convergence view but do not block the delegation→review transition. Include findings in the delegation summary for review-phase attention.

Schema sync — if any task modified API files (
```
*Endpoints.cs
```
,
```
Models/*.cs
```
), run
```
npm run sync:schemas
```

Failure Recovery

When a task fails:

Read the failure output from the runtime's result-collection primitive (
```
inline reply from task --agent (no separate collection API)
```
)
Diagnose root cause — do NOT trust the implementer's self-assessment (see R3 adversarial posture)
Fix the task using the fixer flow below
Run the
```
task-fix
```
runbook gate chain after the fix completes

For the full recovery flow with a concrete example, see

references/worked-example.md

Fix Failed Tasks

Dispatch a fresh fixer agent using the runtime's native spawn primitive, carrying the full failure context and the original task description:

typescript

task --agent fixer 'Fix failed task-001: Your implementation failed. [failure context from test output]. Apply adversarial verification: do NOT trust your previous self-assessment, re-read actual test output, identify root cause not symptoms. [Original task context].'

After fix completes, run the

task-fix

runbook gate chain:

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

If runbook unavailable, use

describe

to retrieve gate schemas:

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

Fix Mode (--fixes)

Handles review failures instead of initial implementation. Uses

references/fixer-prompt.md

template with adversarial verification posture, dispatches fix tasks per issue, then re-invokes review to re-integrate fixes.

Arguments:

--fixes <state-file-path>

— state JSON containing review results in

.reviews.<taskId>.specReview

.reviews.<taskId>.qualityReview

For detailed fix-mode process, see

references/fix-mode.md

Deprecated:
--pr-fixes
has been superseded by
/exarchos:shepherd
. Use the shepherd skill for PR feedback workflows.

Context Compaction Recovery

If context compaction occurs during delegation:

Query workflow state:
```
exarchos_workflow get
```
with
```
fields: ["tasks"]
```
Check active worktrees:
```
ls .worktrees/
```
and verify branch state
Reconcile:
```
exarchos_workflow reconcile
```
replays the event stream and patches stale task state (CAS-protected)
Do NOT re-create branches or re-dispatch agents until confirmed lost

Worktree State Schema

Worktree entries are stored as

worktrees["<wt-id>"]

in workflow state. Each entry requires:

Field	Type	Required	Notes
`branch`	string	Yes	Git branch name
`taskId`	string	Conditional	Single task ID (use for 1-task worktrees)
`tasks`	string[]	Conditional	Multiple task IDs (use for multi-task worktrees)
`status`	`"active"` \| `"merged"` \| `"removed"`	Yes	Worktree lifecycle status

Either

taskId

tasks

(non-empty array) is required — at least one must be present.

Single-task example:

json

{ "branch": "feat/task-001", "taskId": "task-001", "status": "active" }

Multi-task example:

json

{ "branch": "feat/integration", "tasks": ["task-001", "task-002"], "status": "active" }

Phase Transitions and Guards

For the full transition table, consult

@skills/workflow-state/references/phase-transitions.md

Quick reference: The

delegate

→

review

transition requires guard

all-tasks-complete

— all

tasks[].status

must be

"complete"

in workflow state.

Before transitioning to review: You MUST first update all task statuses to
"complete"
via
exarchos_workflow set
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.

Worktree-Bearing Tasks: Auto-Detour to

merge-pending

When a

task.completed

event carries a worktree association (

data.worktree

data.worktreePath

), the HSM auto-transitions through

feature/merge-pending

before reaching

review

. The

next_actions

projection surfaces a

merge_orchestrate

verb (idempotency-keyed by

${streamId}:merge_orchestrate:${taskId}

) so a runtime that consumes

next_actions

will dispatch the merge automatically.

The merge lands the subagent's branch on the integration branch via a local

git merge

with a recorded rollback SHA — see

@skills/merge-orchestrator/SKILL.md

. The HSM exits

merge-pending

back to

delegate

once the merge terminates (

completed

rolled-back

aborted

), at which point

delegate

either re-enters

merge-pending

for the next worktree-bearing task or transitions on to

review

when all delegation is complete.

This detour is invisible to the delegation skill itself — the all-tasks-complete guard still gates the

delegate → review

transition. The merge-pending substate just sits between task completion and the next dispatch decision.

Task Status Values

Status	When to use
`pending`	Task not yet started
`in_progress`	Task actively being worked on
`complete`	Task finished successfully
`failed`	Task encountered an error (requires fix cycle)

Schema Discovery

Use

exarchos_workflow({ action: "describe", actions: ["set", "init"] })

for parameter schemas and

exarchos_workflow({ action: "describe", playbook: "feature" })

for phase transitions, guards, and playbook guidance. Use

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

for orchestrate action schemas.

When integration advances mid-wave

Runbook for recovering when a subagent worktree's branch has diverged from the integration branch. Triggered by

merge_orchestrate

ancestry preflight: the failure message links here verbatim and includes the manual

git rebase

command. Auto-rebase is not wired today (tracked in #1119) — operators must drive recovery by hand.

Symptom

The merge-orchestrator reports an ancestry failure of the form:

text

source branch <feature-branch> is not a descendant of <integration-branch>.
Rebase manually with: git rebase <integration-branch> (run from the <feature-branch> worktree).
Runbook: skills-src/delegation/SKILL.md#when-integration-advances-mid-wave

This means the integration branch advanced (typically because an earlier worktree merge landed) while the failing worktree was still in flight. Fast-forward merge is no longer safe — the working branch must catch up first.

Why this happens

Each subagent worktree is created at the integration branch's tip at dispatch time. When the orchestrator merges sibling worktrees serially, each merge moves the integration branch forward. A worktree that was dispatched against an older integration tip will fail the ancestry preflight when its turn comes.

This is expected behavior under the current single-writer merge contract — preflight is fail-only on purpose so the operator stays in control.

Recovery procedure

Before each step, verify you are in the main worktree (not the failing subagent worktree) and that

git status

is clean.

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.
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.
Re-run ancestry preflight from the main worktree:
typescript
```
exarchos_orchestrate({
  action: "merge_orchestrate",
  featureId: "<featureId>",
  taskId: "<taskId>",
})
```
The preflight should now pass. Proceed with the orchestrator's normal merge flow.

Rollback procedure

If the rebase produces conflicts you cannot resolve safely, or the merge still fails after rebase:

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)"

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.
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.

Why no auto-rebase yet

Auto-rebase is deferred to issue #1119. Today the orchestrator stops at the ancestry preflight on purpose: a botched auto-rebase across diverged worktrees risks silently dropping subagent work, and the recovery path above is short enough that operator-driven rebase is preferable to clever-but-fragile automation.

Transition

After all tasks complete, auto-continue immediately (no user confirmation):

Verify all
```
tasks[].status === "complete"
```
in workflow state
Update state:
```
exarchos_workflow set
```
with
```
phase: "review"
```

Invoke:

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

This is NOT a human checkpoint — the workflow continues autonomously.

References

Document	Purpose
`references/implementer-prompt.md`	Full prompt template for implementation tasks
`references/fixer-prompt.md`	Fix agent prompt with adversarial verification posture
`references/worked-example.md`	Complete delegation trace with recovery path (R1)
`references/rationalization-refutation.md`	Common rationalizations and counter-arguments (R2)
`references/parallel-strategy.md`	Parallel grouping and model selection
`references/testing-patterns.md`	Arrange/Act/Assert, naming, mocking conventions
`references/pbt-patterns.md`	Property-based testing patterns
`references/fix-mode.md`	Detailed fix-mode process
`references/state-management.md`	State patterns and benchmark labeling
`references/troubleshooting.md`	Common failure modes and resolutions
`references/adaptive-orchestration.md`	Adaptive team composition
`references/workflow-steps.md`	Cross-platform step-by-step delegation reference
`references/worktree-enforcement.md`	Worktree isolation rules

delegation

NPX Install

Tags

SKILL.md Content

Delegation Skill

Triggers

Core Principles

Fresh Context Per Task (MANDATORY)

Delegation Modes

Pre-Dispatch Schema Discovery

Step 1: Prepare

Step 0 — Pre-emit (required before
`prepare_delegation`
)

Step 1 — Prepare (readiness check)

Task Extraction

Step 2: Dispatch

Prompt Construction

Decision Runbooks

Parallel Dispatch

Step 3: Monitor and Collect

Subagent Monitoring

Failure Recovery

Fix Failed Tasks

Fix Mode (--fixes)

Context Compaction Recovery

Worktree State Schema

Phase Transitions and Guards

Worktree-Bearing Tasks: Auto-Detour to
`merge-pending`

Task Status Values

Schema Discovery

When integration advances mid-wave

Symptom

Why this happens

Recovery procedure

Rollback procedure

Why no auto-rebase yet

Transition

References

delegation

NPX Install

Tags

SKILL.md Content

Delegation Skill

Triggers

Core Principles

Fresh Context Per Task (MANDATORY)

Delegation Modes

Pre-Dispatch Schema Discovery

Step 1: Prepare

Step 0 — Pre-emit (required before prepare_delegation)

Step 1 — Prepare (readiness check)

Task Extraction

Step 2: Dispatch

Prompt Construction

Decision Runbooks

Parallel Dispatch

Step 3: Monitor and Collect

Subagent Monitoring

Failure Recovery

Fix Failed Tasks

Fix Mode (--fixes)

Context Compaction Recovery

Worktree State Schema

Phase Transitions and Guards

Worktree-Bearing Tasks: Auto-Detour to merge-pending

Task Status Values

Schema Discovery

When integration advances mid-wave

Symptom

Why this happens

Recovery procedure

Rollback procedure

Why no auto-rebase yet

Transition

References

Step 0 — Pre-emit (required before
`prepare_delegation`
)

Worktree-Bearing Tasks: Auto-Detour to
`merge-pending`