delegation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

在具备合适上下文、工作树隔离机制和TDD要求的前提下，将实现任务分配给子Agent。本技能遵循三步流程：准备、分配、监控。

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.

在以下场景激活本技能：

用户执行
```
/delegate
```
命令
实现计划已就绪且可拆分为独立任务
用户希望通过子Agent并行处理任务

例外情况——单次工作流完全跳过任务分配。单次工作流会在主Agent的上下文中运行会话内TDD循环，无需子Agent分配或评审阶段。若

workflowType === "oneshot"

，请勿调用本技能——请查看

@skills/oneshot-workflow/SKILL.md

了解轻量级流程。

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

每个子Agent必须从干净、独立的上下文启动。根据Anthropic多Agent协作最佳实践：

无共享状态假设。每个子Agent的提示语必须包含完整的任务描述、文件路径、TDD要求和验收标准。绝不能使用“查看计划”或“如之前讨论”这类表述。
无跨Agent依赖。除非计划中明确设置了依赖关系，否则子Agent A不得依赖子Agent B的输出。
工作树隔离。每个子Agent在独立的
```
git worktree
```
中操作。同一工作树中的并行Agent会破坏分支状态。

违反此原则的常见合理化借口已记录在

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.

默认的

subagent

模式使用运行时的生成原语

task

分配每个任务。

若

prepare_delegation

任务分类中提供了

recommendedModel

，请使用该模型。若不存在分类（例如修复任务分配），则省略

model

参数，继承会话默认模型。

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

分配任务前，查询决策手册对工作进行分类并选择合适策略：

任务复杂度：调用
```
exarchos_orchestrate({ action: "runbook", id: "task-classification" })
```
获取认知复杂度分类树。低复杂度任务可使用脚手架Agent规格以提升执行速度。
分配策略：调用
```
exarchos_orchestrate({ action: "runbook", id: "dispatch-decision" })
```
获取分配策略（并行/串行、团队规模、隔离模式）。

Step 1: Prepare

步骤1：准备

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.

调用

prepare_delegation

复合操作一次性验证准备状态。此操作替代了手动脚本调用和单独检查。

权威规格：
prepare_delegation
的前置条件、阻塞项和参数的标准列表存储在运行时中——若本技能内容与实际行为不符，可调用
exarchos_orchestrate({ action: "describe", actions: ["prepare_delegation"] })
查询。请将运行时的
describe
输出视为唯一可信来源。

Step 0 — Pre-emit (required before

prepare_delegation

)

步骤0 — 预提交（调用

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 },
  })),
})

调用

prepare_delegation

前，工作流流中必须包含每个任务的

task.assigned

事件。就绪视图会统计这些事件以填充

taskCount

；若无这些事件，

prepare_delegation

将返回

{ ready: false, blockers: ["未找到task.assigned事件..."] }

。

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)

步骤1 — 准备（就绪检查）

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.

typescript

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

复合操作将执行以下内容：

工作树创建——通过

git worktree add

创建

.worktrees/task-<id>

，并运行

npm install

状态验证——验证工作流状态处于
```
delegate
```
阶段，计划已存在且已获批
质量信号收集——查询
```
code_quality
```
视图；若
```
gatePassRate < 0.80
```
，则返回质量提示以嵌入到提示语中。成功时触发
```
gate.executed('plan-coverage')
```
事件（无需预查询）
基准检测——若任何任务包含基准标准，则设置
```
verification.hasBenchmarks
```

就绪判定——返回

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

或

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

若返回
blocked: true
且
reason: "current-branch-protected"
：响应中会包含

hint

字段（例如“分配任务前请切换到feature/phase分支”）。按照提示操作后，重新调用该操作。

若
ready: false
：停止操作。向用户报告原因，请勿继续执行。

若
ready: true
：提取

worktrees

路径和

qualityHints

用于提示语构建。

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

从实现计划中为每个任务提取以下信息：

完整任务描述（直接粘贴；绝不要引用外部文件）
要创建/修改的文件的绝对工作树路径
测试文件路径和预期测试名称
对其他任务的依赖关系（用于任务排序）
属性测试标记（
```
testingStrategy.propertyTests
```
）

有关此流程的完整示例，请查看

references/worked-example.md

。

Step 2: Dispatch

步骤2：分配

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.

使用

references/implementer-prompt.md

作为模板构建子Agent提示语。每个提示语必须包含完整的任务上下文——这是独立上下文原则的实际应用。

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

在具备原生Agent定义的运行时中：

实现者Agent定义已包含系统提示语、模型、隔离设置、技能、钩子和内存。分配提示语应仅包含任务特定上下文：

完整任务描述（需求、验收标准）
工作目录（步骤1中获取的工作树路径）
要创建/修改的文件路径和测试文件路径
质量提示（若有）
当
```
propertyTests: true
```
时的PBT标记

完整提示语模板（默认）：

针对每个任务：

用任务特定信息填充实现者提示语模板
将
```
Working Directory
```
设置为步骤1中获取的工作树路径
在Quality Signals部分包含质量提示（若有）

当

propertyTests: true

时，包含

references/pbt-patterns.md

中的PBT部分

包含
```
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.

若需制定分配策略决策，请查询决策手册：

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

该手册提供了并行/串行分配、团队规模和故障升级的结构化标准。

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

使用运行时的原生生成原语，在单条消息中分配所有独立任务，使任务并行运行。

typescript

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

注意：在分配负载中包含
references/implementer-prompt.md
中的完整实现者提示语模板，使生成的Agent具备独立上下文——将实现者提示语预绑定到命名Agent的运行时会自动丢弃冗余内容。

有关并行分组策略和模型选择，请查看

references/parallel-strategy.md

。

Step 3: Monitor and Collect

步骤3：监控与收集

Subagent Monitoring

子Agent监控

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

使用运行时的结果收集原语收集后台任务结果（根据运行时不同，可能为每个任务轮询/等待或内回复）：

text

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

每个子Agent报告完成后：

手册：针对每个已完成任务，执行任务完成手册：
exarchos_orchestrate({ action: "runbook", id: "task-completion" })
按顺序执行返回的步骤。若检查项失败则停止。若该手册操作不可用，请使用
describe
获取检查项模式并手动执行：
exarchos_orchestrate({ action: "describe", actions: ["check_tdd_compliance", "check_static_analysis", "task_complete"] })

从子Agent报告中提取来源信息——解析子Agent的完成输出并提取结构化来源字段（
```
implements
```
、
```
tests
```
、
```
files
```
）。这些字段由子Agent根据实现者提示语中的来源报告部分提供。
验证工作树状态——确认每个工作树的
```
git status
```
干净且测试通过
执行阻塞检查项——上述
```
task-completion
```
手册定义了确切的检查项顺序（TDD合规性、静态分析、task_complete）。若任何检查项失败，将任务标记为进行中并报告结果。所有检查项处理程序会自动触发
```
gate.executed
```
事件，无需手动调用
```
exarchos_event
```
。
在任务完成时传递来源信息——标记任务完成时，在
```
result
```
参数中传递提取的来源字段，使其流入
```
task.completed
```
事件：

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

更新工作流状态——通过
```
exarchos_workflow set
```
将每个已完成任务的
```
tasks[].status
```
设置为
```
"complete"
```
任务分配完成检查项（D4，建议执行）——所有任务完成后，在切换到评审阶段前，对完整分支差异执行操作弹性检查：

typescript

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

此检查项为建议执行——结果会记录到聚合视图中，但不会阻止从分配到评审的阶段切换。请将结果包含在任务分配总结中供评审阶段参考。

模式同步——若任何任务修改了API文件（
```
*Endpoints.cs
```
、
```
Models/*.cs
```
），请运行
```
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

任务失败时：

从运行时的结果收集原语中读取失败输出（
```
inline reply from task --agent (no separate collection API)
```
）
诊断根本原因——不要轻信实现者的自我评估（请参阅R3对抗性姿态）
使用以下修复流程修复任务
修复完成后运行
```
task-fix
```
手册检查项链

有关包含具体示例的完整恢复流程，请查看

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

使用运行时的原生生成原语分配新的修复Agent，携带完整的失败上下文和原始任务描述：

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

修复完成后，运行

task-fix

手册检查项链：

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

若手册不可用，请使用

describe

获取检查项模式：

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

Fix Mode (--fixes)

修复模式（--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.

处理评审失败而非初始实现问题。使用

references/fixer-prompt.md

模板并采用对抗性验证姿态，针对每个问题分配修复任务，然后重新调用评审以整合修复内容。

参数：

--fixes <state-file-path>

——包含评审结果的状态JSON，存储在

.reviews.<taskId>.specReview

或

.reviews.<taskId>.qualityReview

中。

有关修复模式的详细流程，请查看

references/fix-mode.md

。

已弃用：
--pr-fixes
已被
/exarchos:shepherd
取代。请使用shepherd技能处理PR反馈工作流。

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

若任务分配过程中发生上下文压缩：

查询工作流状态：调用
```
exarchos_workflow get
```
并设置
```
fields: ["tasks"]
```
检查活动工作树：执行
```
ls .worktrees/
```
并验证分支状态
协调：调用
```
exarchos_workflow reconcile
```
重放事件流并修补过期任务状态（受CAS保护）
在确认任务丢失前，请勿重新创建分支或重新分配Agent

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

工作树条目存储在工作流状态的

worktrees["<wt-id>"]

中。每个条目需要包含以下字段：

字段	类型	是否必填	说明
`branch`	string	是	Git分支名称
`taskId`	string	可选	单个任务ID（用于单任务工作树）
`tasks`	string[]	可选	多个任务ID（用于多任务工作树）
`status`	`"active"` \| `"merged"` \| `"removed"`	是	工作树生命周期状态

必须填写

taskId

或

tasks

（非空数组）中的至少一项。

单任务示例：

json

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

多任务示例：

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.

有关完整的转换表，请参阅

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

。

快速参考：从

delegate

到

review

的转换需要

all-tasks-complete

检查项——工作流状态中所有

tasks[].status

必须为

"complete"

。

转换到评审阶段前：必须先通过
exarchos_workflow set
更新所有任务状态为
"complete"
。若任何任务仍处于pending/in_progress/failed状态，阶段转换会被检查项拒绝。请先更新任务状态，再通过单独调用设置阶段。

Worktree-Bearing Tasks: Auto-Detour to

merge-pending

关联工作树的任务：自动转入

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

事件携带工作树关联信息（

data.worktree

或

data.worktreePath

）时，HSM会在进入

review

阶段前自动转换到

feature/merge-pending

状态。

next_actions

投影会显示

merge_orchestrate

操作（幂等键为

${streamId}:merge_orchestrate:${taskId}

），因此读取

next_actions

的运行时会自动触发合并操作。

合并操作通过本地

git merge

将子Agent的分支合并到集成分支，并记录回滚SHA——请查看

@skills/merge-orchestrator/SKILL.md

。合并完成（

completed

rolled-back

aborted

）后，HSM会从

merge-pending

状态退出回到

delegate

状态，此时

delegate

状态要么为下一个关联工作树的任务重新进入

merge-pending

状态，要么在所有任务分配完成后转换到

review

状态。

此分支流程对任务分配技能不可见——

all-tasks-complete

检查项仍会控制

delegate → review

的转换。merge-pending子状态仅存在于任务完成和下一次分配决策之间。

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)

状态	使用场景
`pending`	任务尚未开始
`in_progress`	任务正在进行中
`complete`	任务成功完成
`failed`	任务遇到错误（需要修复循环）

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.

调用

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

获取参数模式；调用

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

获取阶段转换、检查项和工作流指南；调用

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

获取编排操作模式。

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.

当子Agent工作树的分支与集成分支出现差异时的恢复手册。由

merge_orchestrate

祖先预检查触发：失败消息会直接链接到此处，并包含手动

git rebase

命令。目前未支持自动变基（跟踪在#1119中）——操作人员必须手动执行恢复操作。

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.

合并编排器会报告如下形式的祖先检查失败：

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

这意味着集成分支已更新（通常是因为较早的工作树合并已完成），而当前失败的工作树仍在处理中。此时快速前向合并已不安全——工作分支必须先同步到最新状态。

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.

每个子Agent工作树在分配时基于集成分支的最新创建。当编排器串行合并同级工作树时，每次合并都会推进集成分支。基于旧集成分支版本分配的工作树在轮到它时会触发祖先预检查失败。

这是当前单写入者合并协议下的预期行为——预检查故意设置为失败即停止，以便操作人员保持控制。

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.

执行每个步骤前，请确认你处于主工作树（而非失败的子Agent工作树）且

git status

干净。

捕获回滚SHA，然后再执行任何破坏性操作：
bash
```
git rev-parse <feature-branch> > /tmp/rollback.sha
```
请保留此文件直到合并验证完成。若出现任何问题，在功能分支上执行
```
git reset --hard "$(cat /tmp/rollback.sha)"
```
即可恢复变基前的状态。文件名故意不包含分支名称，避免像
```
feature/dr-6
```
这类带斜杠的分支破坏路径。
将功能分支变基到当前集成分支的最新版本：
bash
```
cd <feature-worktree-path>
git fetch origin
git rebase <integration-branch>
```
解决出现的任何冲突。这些冲突是真实存在的——反映了两个分支之间的实际差异，而非预检查误报。请勿盲目使用
```
--strategy-option=theirs
```
参数；这会丢弃子Agent的工作成果。
从主工作树重新执行祖先预检查：
typescript
```
exarchos_orchestrate({
  action: "merge_orchestrate",
  featureId: "<featureId>",
  taskId: "<taskId>",
})
```
预检查现在应该会通过。继续执行编排器的正常合并流程。

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.

若变基产生无法安全解决的冲突，或变基后合并仍失败：

将功能分支重置到捕获的回滚SHA：

bash

cd <feature-worktree-path>
git rebase --abort   # 若正在变基中
git reset --hard "$(cat /tmp/rollback.sha)"

**在工作流状态中将任务标记为
```
failed
```
**并分配修复Agent（请参阅上述故障恢复部分）。请勿删除工作树——修复Agent需要原始分支状态来诊断冲突。
记录事件——触发
```
merge.aborted
```
事件，设置
```
reason: "ancestry-rebase-conflict"
```
并包含失败分支变基前的SHA，以便聚合视图捕获回滚操作。

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.

自动变基功能推迟到#1119号问题处理。目前编排器在祖先预检查阶段停止是有意为之：在分支差异较大的情况下，错误的自动变基可能会无声丢弃子Agent的工作成果，而上述恢复流程足够简短，操作人员手动变基比复杂但脆弱的自动化更可靠。

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.

所有任务完成后，立即自动继续（无需用户确认）：

验证工作流状态中所有
```
tasks[].status === "complete"
```
更新状态：调用
```
exarchos_workflow set
```
并设置
```
phase: "review"
```

调用：

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

这并非人工检查点——工作流会自动继续执行。

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

文档	用途
`references/implementer-prompt.md`	实现任务的完整提示语模板
`references/fixer-prompt.md`	采用对抗性验证姿态的修复Agent提示语
`references/worked-example.md`	包含恢复流程的完整任务分配跟踪示例（R1）
`references/rationalization-refutation.md`	常见合理化借口及反驳论据（R2）
`references/parallel-strategy.md`	并行分组和模型选择策略
`references/testing-patterns.md`	Arrange/Act/Assert、命名、模拟约定
`references/pbt-patterns.md`	属性测试模式
`references/fix-mode.md`	修复模式详细流程
`references/state-management.md`	状态模式和基准标记
`references/troubleshooting.md`	常见故障模式及解决方案
`references/adaptive-orchestration.md`	自适应团队组成
`references/workflow-steps.md`	跨平台分步任务分配参考
`references/worktree-enforcement.md`	工作树隔离规则

delegation

Original

Translation

Delegation Skill

任务分配技能

Triggers

触发条件

Core Principles

核心原则

Fresh Context Per Task (MANDATORY)

每个任务独立上下文（强制要求）

Delegation Modes

分配模式

Pre-Dispatch Schema Discovery

分配前模式发现

Step 1: Prepare

步骤1：准备

Step 0 — Pre-emit (required before prepare_delegation)

步骤0 — 预提交（调用prepare_delegation前必须执行）

Step 1 — Prepare (readiness check)

步骤1 — 准备（就绪检查）

Task Extraction

任务提取

Step 2: Dispatch

步骤2：分配

Prompt Construction

提示语构建

Decision Runbooks

决策手册

Parallel Dispatch

并行分配

Step 3: Monitor and Collect

步骤3：监控与收集

Subagent Monitoring

子Agent监控

Failure Recovery

故障恢复

Fix Failed Tasks

修复失败任务

Fix Mode (--fixes)

修复模式（--fixes）

Context Compaction Recovery

上下文压缩恢复

Worktree State Schema

工作树状态模式

Phase Transitions and Guards

阶段转换与检查项

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

关联工作树的任务：自动转入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`
)

步骤0 — 预提交（调用
`prepare_delegation`
前必须执行）

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

关联工作树的任务：自动转入
`merge-pending`
状态