Plan Orchestrate (计划编排)
通过为每个步骤生成一个可直接粘贴的 /orchestrate custom 调用来桥接计划文档。该技能仅限生成——它从不执行 /orchestrate。用户在准备好的时候粘贴每一行。
何时激活
- 用户有一个多步骤计划文档（PRD、RFC、实施计划）并希望通过
/orchestrate驱动它。 - 用户说“编排这个计划”、“为每个步骤提供编排提示”、“为此计划组合链”。
- 存在一个逐步计划，但用户不想手动为每个步骤挑选 Agent。
跳过情况：
- 工作是单一临时步骤 → 直接调用
/orchestrate custom。 - 计划不可读或为空。仅仅缺少明确的编号不是跳过条件——请参阅下面的“无明确步骤”边界情况。
输入
<plan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]
<plan-doc-path>— 必需；相对或绝对路径（接受@docs/...）。--lang— 审查者语言变体；默认为auto（从项目中检测）。--scope— 限制发出的步骤；默认为all。--dry-run— 仅打印分解和链基本原理；不发出最终提示。
权威的 /orchestrate 形态（不可偏离）
{ORCH_CMD} custom "<agent1>,<agent2>,...,<agentN>" "<task description>"
其中 {ORCH_CMD} 在第 0 阶段确定（见下文）。发出的输出中的命令字符串始终使用一种具体形式——绝不使用两种，绝不使用占位符。
custom是一个顺序链；每个 Agent 的 HANDOFF 会馈送到下一个。- 以逗号分隔的 Agent 列表。无空格优先；允许一个空格。
- 不存在
--mode/--gate/--agents=...标志——切勿发明它们。 - Agent 名称来自此技能中的目录。任务描述中的嵌入双引号转义为
\"。
ECC 安装形式和命名空间
两种安装形式决定了斜杠命令和每个 Agent 名称上的前缀。两个必须保持同步——每个输出一种形式，绝不混合：
让 <claude-home> 表示 Claude Code 主目录：macOS/Linux 上为 ~/.claude，Windows 上为 %USERPROFILE%\.claude。按照宿主平台解析用户主目录的方式解析它（不要硬编码 ~）。
| 形式 | 检测 | {ORCH_CMD} | Agent 名称格式 |
|---|---|---|---|
| 插件安装 (2.0.0+) | <claude-home>/plugins/marketplaces/ecc/ 存在 | /ecc:orchestrate | ecc:<name> |
| 传统裸安装 | 上述不存在；Agent 文件在 <claude-home>/agents/ 下 | /orchestrate | <name> |
为什么重要：在插件安装下，Agent 注册为 ecc:tdd-guide。裸名称强制进行模糊匹配，这在并行调用下会间歇性失败。在传统模式下，前缀形式未注册且会完全失败。
可用 Agent 目录（必须从这些中选择）
通用：
planner— 需求重述、风险分解、步骤规划architect— 架构、系统设计、重构建议tdd-guide— 编写测试 → 实现 → 80%+ 覆盖率code-reviewer— 通用代码审查security-reviewer— 安全审计、OWASP、秘密泄露refactor-cleaner— 死代码、重复、knip 类清理doc-updater— 文档、代码映射、READMEdocs-lookup— 第三方库 API 查找 (Context7)e2e-runner— 端到端测试编排database-reviewer— PostgreSQL 模式、迁移、性能harness-optimizer— 本地 Agent 配置loop-operator— 长时间运行的自洽循环chief-of-staff— 多通道分类（很少适合计划步骤）
构建错误解析器：
build-error-resolver（通用）/cpp-build-resolver/go-build-resolver/java-build-resolver/kotlin-build-resolver/rust-build-resolver/pytorch-build-resolver
代码审查者：
python-reviewer/typescript-reviewer/go-reviewer/rust-reviewer/cpp-reviewer/java-reviewer/kotlin-reviewer/flutter-reviewer
拼写错误的 Agent 名称会导致 /orchestrate 失败。在发出之前，请对照此列表进行交叉检查。
工作原理
第 0 阶段 — 检测 ECC 模式 + 语言
-
读取
<plan-doc-path>。如果缺失或为空，则报告并停止。 -
检测一次 ECC 安装形式并将其冻结为
ECC_MODE。算法（按顺序运行，在第一个匹配处停止）：- 如果
<claude-home>/plugins/marketplaces/ecc/存在 →ECC_MODE=plugin。 - 否则，如果
<claude-home>/agents/存在且包含至少一个 ECC Agent 文件（例如tdd-guide.md、code-reviewer.md）→ECC_MODE=legacy。 - 否则 → 默认为
ECC_MODE=legacy并在输出顶部发出一行警告：> Warning: could not detect ECC install; defaulting to legacy form. If you use the plugin install, edit the prefixes manually. - 如果两个标记都存在（混合安装），则
plugin获胜——插件命名空间是唯一无需模糊匹配即可解析 Agent 名称的命名空间。
从这一点开始，每个发出的行都在斜杠命令和每个 Agent 名称上使用匹配的前缀。切勿在同一个输出中发出两种形式。
- 如果
-
解析
--lang。当为auto时，运行多语言感知检测：- 探测标记：
pyproject.toml/uv.lock/requirements.txt→ python；package.json→ typescript；go.mod→ go；Cargo.toml→ rust；CMakeLists.txt或顶层*.cpp→ cpp；pom.xml/build.gradle（Java）→ java；build.gradle.kts或顶层 Kotlin → kotlin；pubspec.yaml→ flutter。 - 多语言决胜：如果匹配了多个标记，选择源文件数量超过其他的语言（通过
git ls-files计数，排除vendor/、node_modules/、dist/、build/、.venv/、生成的文件和明显的测试夹具）。平局或没有语言超过源文件的 60% 时，设置lang=unknown。 - 未匹配到标记 → 设置
lang=unknown。 lang=unknown是一个哨兵——它不是一个 Agent 名称。第 2 阶段的规则 4 和 5 在链组合时将其转换为code-reviewer/build-error-resolver。
- 探测标记：
-
检测 PyTorch 子配置文件：当
lang=python并且pyproject.toml/requirements.txt/uv.lock中的任何一个声明了对torch的依赖时，设置pytorch=true。这仅影响build链选择（下面的第 2 阶段规则）；审查者保持为python-reviewer。 -
规范化计划中声明的任何 Agent 名称：如果计划文本通过插件前缀形式引用 Agent（例如
ecc:tdd-guide），则剥离前缀以在验证或组合链之前获取裸目录名称。仅在输出时间根据ECC_MODE（第 4 阶段）进行重新前缀。绝不让预前缀的名称流入链组合——这将导致在插件模式下出现双重前缀。
第 1 阶段 — 分解步骤
按优先级顺序识别“步骤单元”：
- 明确编号：
## Step N/### Phase N/## N. .../ 顶层有序列表。 - 表格中的“Step”列。
---分隔的块，带有以动词开头的标题。- 否则将每个 H2 视为一个步骤。
为每个步骤提取 id（从 1 开始）、title（≤ 80 个字符）、intent（1–3 个句子）、tags。
第 2 阶段 — 标记和选择链
按意图进行标记（允许多个标记；链由主要 + 堆叠的次要构建）：
下面的触发词以不区分大小写的方式匹配。支持多语言计划，只要含义与列出的英文触发词对齐，就匹配任何语言中的词干。
| 标签 | 触发词 | 默认链 |
|---|---|---|
design | architecture, design, choose, evaluate, RFC | planner,architect |
plan | plan, breakdown, milestone | planner |
impl | implement, build, add, create, port | tdd-guide,<lang>-reviewer |
test | test, coverage, e2e, integration | tdd-guide,e2e-runner |
refactor | refactor, cleanup, dedupe, split | architect,refactor-cleaner,<lang>-reviewer |
migration | migrate, upgrade, rewrite, port | architect,tdd-guide,<lang>-reviewer |
db | schema, migration, index, SQL, Postgres, alembic, sqlmodel | database-reviewer,<lang>-reviewer |
security | encrypt, auth, secret, OWASP, PII | security-reviewer,<lang>-reviewer |
build | build, compile, lint failure, CI | <lang>-build-resolver（回退到 build-error-resolver） |
docs | docs, readme, codemap, changelog | doc-updater |
lookup | lookup, reference, API usage | docs-lookup |
review | review, audit, verify | <lang>-reviewer,code-reviewer |
loop | loop, autonomous, watchdog | loop-operator |
链组合规则：
- 主要标签选择：当一个步骤匹配多个标签时，表格顺序中的第一个（表格顶部 = 最高优先级）是主要的；其余的是次要的。下面的组合规则 2 和 3 明确处理特定的多标签组合；否则，按标签表顺序附加次要链。
impl+security→tdd-guide,<lang>-reviewer,security-reviewer。impl+db→tdd-guide,database-reviewer,<lang>-reviewer。- 去重结果链（保留第一次出现）。例如，
review+lang=unknown将在规则 5 之后产生code-reviewer,code-reviewer；去重将其折叠为code-reviewer。 - 当
lang=unknown时，<lang>-reviewer解析为code-reviewer。 - 当
lang=unknown时，<lang>-build-resolver解析为build-error-resolver。特殊情况：如果第 0 阶段设置了pytorch=true，则无论<lang>如何，对于build链使用pytorch-build-resolver。没有python-build-resolver；没有pytorch=true的--lang=python解析为build-error-resolver。 - 零标签步骤：如果没有匹配到触发词，将链设置为
code-reviewer，并在“链基本原理”下写入no tag matched; default review-only chain。 - 去重后链长度 ≤ 4。如果超过，则删除最弱的标签（
lookup和docs优先）。 - 不要在
impl链中配对planner和architect（令牌浪费）。仅在design步骤中配对它们。 - 标记为
impl、refactor或migration的步骤以审查者类 Agent 结束——可以是<lang>-reviewer、code-reviewer、security-reviewer或database-reviewer中的任何一个。最具领域专业知识的审查者赢得尾部位置（例如，规则 2 的impl+security以security-reviewer结束；规则 3 的impl+db以<lang>-reviewer结束，因为database-reviewer已经在链中较早地监督迁移）。test和build步骤由其自己的验证器（分别是e2e-runner和构建解析器）监督，不需要额外的审查者。
第 3 阶段 — 压缩任务描述
每个发出的 <task description> 必须：
- 是自包含的（第一个 Agent 不需要打开计划文档）。
- 以
[Plan: <path>#step-<id>]开头。 - 包含 1–3 个可验证的验收标准。
- 仅当计划为此步骤声明了范围时才包含范围防护（
Out of scope: ...）。逐字继承。如果计划没有范围外的声明，则完全省略该子句——不要自己发明一个。 - 为 200–600 个字符；一行；嵌入的
"转义为\"；没有文字换行符。
第 4 阶段 — 输出
使用由 ECC_MODE 确定的形式发出 Markdown。输出全程使用一种形式——每个 {ORCH_CMD} 和每个 Agent 名称都使用来自第 0 阶段的匹配前缀进行渲染。不要发出两种形式；不要在渲染的输出中包含“这是插件形式” / “去除前缀”的指令。
具体渲染规则：
{ORCH_CMD}= 在plugin下为/ecc:orchestrate，在legacy下为/orchestrate。{AGENT(name)}= 在plugin下为ecc:<name>，在legacy下为<name>。- 概览表中的“Chain”列使用相同的
{AGENT(name)}渲染。 - 每个步骤的 bash 块仅包含可运行的命令。没有
# plugin form或# legacy form注释——形式是隐式的，并且在整体输出中保持一致。
输出结构：
# Plan-Orchestrate Result
**Plan**: `<path>`
**Lang**: `<detected-or-given>`
**ECC mode**: `<plugin | legacy>`
**Steps**: <N>
**Scope**: <all | step:n | range:a-b>
## Steps overview
| # | Title | Tags | Chain |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |
---
## Step 1 — <title>
**Intent**: <1–3 sentences>
**Tags**: <a, b>
**Chain rationale**: <why this chain; which agent closes the loop>
```bash
{ORCH_CMD} custom "{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}" "[Plan: docs/foo.md#step-1] <compressed task description>; Acceptance: <1–3 items>; Out of scope: <…>"
> 上面的 `{ORCH_CMD}` 和 `{AGENT(...)}` 符号描述了此技能在运行时执行的替换。实际发出的 Markdown 包含已解析的字符串，绝不包含占位符。
追加一个最终的“批处理执行”块，按顺序聚合每个步骤的命令，以便用户可以一次性粘贴所有这些命令。**在仅概览模式下跳过批处理块**（参见“大型计划”边界情况）：当仅发出概览表时，没有要聚合的每个步骤命令。
### 第 5 阶段 — 自检（在发出前运行）
- [ ] 每个链中的每个 Agent 都来自目录（在去除了计划中出现的任何 `ecc:` 前缀之后；请参阅第 0 阶段步骤 5）。
- [ ] 已解析的 `{ORCH_CMD}` 和每个已解析的 `{AGENT(...)}` 使用**相同**的形式（`plugin` 或 `legacy`）——在一个输出中绝不混合。
- [ ] 渲染的输出中不保留 `# plugin form` / `# legacy form` 注释和没有“去除前缀”的指令。
- [ ] 没有发明的 `--mode` / `--gate` / `--agents=...` 字段。
- [ ] 每个任务描述都是单行、双引号，嵌入的 `"` 已转义。
- [ ] 每个任务描述以 `[Plan: <path>#step-<id>]` 开头，并包含验收标准（1–3 项）。仅当从计划继承时才存在 `Out of scope:` 子句。
- [ ] 在第 2 阶段去重后，任何链中都没有重复的 Agent。
- [ ] 链长度 ≤ 4。
- [ ] 标记为 `impl`/`refactor`/`migration` 的步骤以审查者类 Agent 结束。
- [ ] 任务描述为 200–600 个字符。
- [ ] 当 `--scope` 限制步骤时，输出不包含该范围之外的步骤。
## 边界案例
### 无明确步骤
当计划没有编号或表格时，技能仍应尽力分解。这包括用自然语言编写的计划（例如“First, implement the auth module. Then, add tests. Finally, update the docs.”）。在这种情况下，使用简单的句子分割来识别步骤，并将每个句子视为一个潜在的步骤。在“链基本原理”中注明 `steps derived from natural language parsing`。在每个步骤的任务描述中将步骤 ID 格式化为 `step-<sentence-number>`。
### 大型计划（>= 15 个步骤）
发出时：
1. 仅概览表。
2. 对第一个（3）个步骤进行完整的步一步扩展，以说明模式。
3. 一条注释：`*Only the first 3 steps are expanded. Paste any line from the overview table to expand that step.*`
4. 跳过批处理执行块（没有命令可聚合）。
### 部分范围
当 `--scope=step:3` 或 `--scope=range:2-5` 时，输出中仅包含这些步骤及其命令。批处理执行块也仅限于该范围。
### 计划中的代码块
在压缩任务描述时，从计划中保留任何不超过 50 行的代码块，但在两边添加 `snip` 注释：
// snip: relevant code from plan // snip end
超过 50 行的代码块将被替换为 `<code truncated; see plan at <path>>`。
### 未知语言
当 `lang=unknown` 时（第 0 阶段或通过 `--lang=unknown`），任务描述应说明：`Reviewer language not auto-detectable; using generic agents.`。此警告也出现在输出顶部的“Lang”行中。
### 重复的计划步骤
如果两个步骤具有相同的标题和 80%+ 的意图重叠，则将它们合并为一个步骤，在标题后附加 `(merged)`，并在“链基本原理”中注明 `Duplicates: step <id> and <id> merged`。
### 依赖信息
如果计划文本包含“Depends on: step <N>”、“prerequisite”、“blocked by”或类似的依赖语言，则向任务描述追加一个 `Context:` 子句：`Context: requires <step title> from step <ref-id> first`。如果引用的步骤在范围内，请确保在输出中将其放置在依赖步骤之前。依赖链可以嵌套，但仅分解到直接依赖（即，如果步骤 3 依赖于步骤 2，而步骤 2 依赖于步骤 1，则步骤 3 的任务描述只说 `Context: requires <step 2 title> first`；不要遍历整个图）。嵌套顺序由输出严格区分——如果依赖在范围外，则将引用任务描述为 `Context: depends on <step title> which is outside the current scope`。