delegation

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 /exarchos: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.

On Claude Code (and any future runtime declaring team:agent-teams), an additional agent-team mode is available — Task invocations bind to a team_name for interactive multi-pane coordination.

Mode	Mechanism	Best for
`subagent` (default)	runtime spawn primitive	1-3 independent tasks, CI, headless
`agent-team`	`Task` with `team_name`	3+ interdependent tasks, interactive sessions

Auto-detection: tmux + CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS present means agent-team. Otherwise subagent. Override with /exarchos:delegate --mode subagent|agent-team.

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

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)

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: [...] } or { 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.

Task({
  subagent_type: "exarchos-implementer",
  run_in_background: true,
  description: "Implement task-001: [title]",
  prompt: "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.

Agent Teams Dispatch

When using --mode agent-team, follow the 6-step saga in references/agent-teams-saga.md. The saga requires event-first execution: emit event, then execute side effect at every step.

Event emission contract for agent teams: see references/agent-teams-saga.md for full payload shapes and compensation protocol.

Event Emission Contract (REQUIRED)

The delegate phase requires these events (checked by check-event-emissions):

Event	When	Emitted By
`task.assigned`	Before `prepare_delegation` (one per task; see Step 0)	Orchestrator
`team.spawned`	After team creation, before dispatch	Orchestrator
`team.task.planned`	For each task in the plan (use `batch_append`)	Orchestrator
`team.teammate.dispatched`	After each subagent is spawned	Orchestrator
`task.progressed`	After each TDD phase (red/green/refactor)	Subagent
`team.disbanded`	After all subagents complete	Orchestrator

See references/agent-teams-saga.md for full event schemas and emission order.

Note: task.progressed events are emitted by subagents during TDD execution, not by the orchestrator. The orchestrator only emits team lifecycle events.

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

TaskOutput({ task_id, block: true })

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:

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:

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

Agent Teams Monitoring

Teammates visible in tmux split panes
TeammateIdle hook auto-runs quality gates and emits completion/failure events
Orchestrator monitors via exarchos_view delegation_timeline for bottleneck detection
See references/agent-teams-saga.md for disbanding and reconciliation

Failure Recovery

When a task fails:

Read the failure output from the runtime's result-collection primitive (TaskOutput({ task_id, block: true }))
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:

Task({
  subagent_type: "exarchos-fixer",
  run_in_background: true,
  description: "Fix failed task-001",
  prompt: "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]."
})

Optimization (opt-in): On runtimes with native session resume (e.g. Claude Code with an agentId in workflow state), you may resume the original agent instead so it retains its implementer context. Fresh dispatch above remains correct and is the canonical default.

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 or .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 or tasks (non-empty array) is required — at least one must be present.

Single-task example:

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

Multi-task example:

{ "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 or 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:

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:
```
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:
```
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:
```
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:

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: Skill({ skill: "exarchos:review", 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)