计划编排 是做什么的？
将计划文档桥接到 /orchestrate custom，并为每一步生成一个可直接粘贴的调用命令。该技能仅用于生成——它从不执行 /orchestrate。用户可在准备好时逐条粘贴。
何时激活
- 用户拥有多步骤计划文档（PRD、RFC、实施计划）并希望通过
/orchestrate驱动它。 - 用户说“编排这个计划”、“为每一步生成编排提示”、“为此计划组合链”。
- 存在逐步计划，但用户不想手动为每一步选择智能体。
跳过的情况：
- 工作是单一步骤 → 直接调用
/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是顺序链；每个智能体的 HANDOFF 传递给下一个。- 逗号分隔的智能体列表。无空格优先；容忍一个空格。
- 不存在
--mode/--gate/--agents=...标志——切勿发明它们。 - 智能体名称来自本技能中的目录。任务描述中的嵌入双引号应转义为
\"。
ECC 安装形式和命名空间
两种安装形式决定了斜杠命令和每个智能体名称的前缀。两者必须保持同步——每次输出只使用一种形式，永不混合：
令 <claude-home> 表示 Claude Code 主目录：macOS/Linux 上为 ~/.claude，Windows 上为 %USERPROFILE%\.claude。按照宿主平台解析用户主目录的方式解析（不要硬编码 ~）。
| 形式 | 检测 | {ORCH_CMD} | 智能体名称格式 |
|---|---|---|---|
| 插件安装 (2.0.0+) | <claude-home>/plugins/marketplaces/ecc/ 存在 | /ecc:orchestrate | ecc:<name> |
| 旧版裸安装 | 上述不存在；智能体文件位于 <claude-home>/agents/ | /orchestrate | <name> |
为何重要：在插件安装下，智能体注册为 ecc:tdd-guide。裸名称会强制进行模糊匹配，在并行调用下可能间歇性失败。在旧版下，前缀形式未注册，会直接失败。
可用智能体目录（必须从中选择）
通用：
planner— 需求重述、风险分解、步骤规划architect— 架构、系统设计、重构建议tdd-guide— 编写测试 → 实现 → 80%+ 覆盖率code-reviewer— 通用代码审查security-reviewer— 安全审计、OWASP、秘密泄露refactor-cleaner— 死代码、重复、knip-class 清理doc-updater— 文档、代码映射、READMEdocs-lookup— 第三方库 API 查找 (Context7)e2e-runner— 端到端测试编排database-reviewer— PostgreSQL 架构、迁移、性能harness-optimizer— 本地智能体工具包配置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
拼写错误的智能体名称会导致 /orchestrate 失败。在输出前请对照此列表检查。
工作原理
阶段 0 — 检测 ECC 模式和语言
-
读取
<plan-doc-path>。如果缺失或为空，报告并停止。 -
检测 ECC 安装形式一次，并冻结为
ECC_MODE。算法（按顺序执行，在第一个匹配处停止）：- 如果
<claude-home>/plugins/marketplaces/ecc/存在 →ECC_MODE=plugin。 - 否则如果
<claude-home>/agents/存在且至少包含一个 ECC 智能体文件（例如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优先级更高——插件命名空间是唯一能无需模糊匹配解析智能体名称的命名空间。
从此刻起，输出的每一行都使用匹配的前缀，同时应用于斜杠命令和每个智能体名称。永远不要在同一个输出中同时输出两种形式。
- 如果
-
解析
--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是一个哨兵值——它不是智能体名称。阶段 2 的规则 4 和 5 在链组合时将其转换为code-reviewer/build-error-resolver。
- 探测标记：
-
检测 PyTorch 子配置文件：当
lang=python且pyproject.toml/requirements.txt/uv.lock中任何一个声明了对torch的依赖时，设置pytorch=true。这仅影响build链选择（下面的阶段 2 规则）；审查员保持为python-reviewer。 -
规范化计划中声明的任何智能体名称：如果计划文本引用了插件前缀形式的智能体（例如
ecc:tdd-guide），剥离前缀以在验证或组合链之前获得裸目录名称。重新添加前缀仅在输出时根据ECC_MODE进行（阶段 4）。绝不允许预先添加前缀的名称流入链组合——否则在插件模式下会双重添加前缀。
阶段 1 — 分解步骤
按优先级顺序识别“步骤单元”：
- 明确编号：
## Step N/### Phase N/## N. .../ 顶层有序列表。 - 表格中的“步骤”列。
---分隔的块，带有动词开头的标题。- 否则，将每个 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，则对于build链使用pytorch-build-resolver，无论<lang>是什么。没有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（浪费 token）。仅在design步骤中配对它们。 - 标记为
impl、refactor或migration的步骤以审查员类智能体结束——可以是<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> 必须：
- 是自包含的（第一个智能体不需要打开计划文档）。
- 以
[Plan: <path>#step-<id>]开头。 - 包含 1–3 条可验证的验收标准。
- 仅当计划为此步骤声明了范围时，才包含范围保护（
Out of scope: ...）。逐字继承。如果计划没有范围外声明，则完全省略该子句——不要发明一个。 - 长度为 200–600 字符；单行；嵌入的
"转义为\"；无字面换行。
阶段 4 — 输出
使用由 ECC_MODE 确定的形式输出 Markdown。输出始终使用一种形式——每个 {ORCH_CMD} 和每个智能体名称都使用阶段 0 的匹配前缀渲染。不要输出两种形式；不要在渲染输出中包含“这是插件形式”/“剥离前缀”的说明。
具体渲染规则：
{ORCH_CMD}=/ecc:orchestrate（plugin下），/orchestrate（legacy下）。{AGENT(name)}=ecc:<name>（plugin下），<name>（legacy下）。- 概览表格的“链”列使用相同的
{AGENT(name)}渲染。 - 每步的 bash 代码块仅包含可运行的命令。没有
# plugin form或# legacy form注释——形式是隐式的，并且在整个输出中保持一致。
输出结构：
# 计划编排结果
**计划**: `<path>`
**语言**: `<detected-or-given>`
**ECC 模式**: `<plugin | legacy>`
**步骤**: <N>
**范围**: <all | step:n | range:a-b>
## 步骤概览
| # | 标题 | 标签 | 链 |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |
---
## 步骤 1 — <title>
**意图**: <1–3 句话>
**标签**: <a, b>
**链理由**: <为什么选择此链；哪个智能体完成循环>
```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 — 自我检查（在输出前执行）
- [ ] 每个链中的每个智能体都来自目录（在剥离计划中出现的任何 `ecc:` 前缀后；参见阶段 0 步骤 5）。
- [ ] 已解析的 `{ORCH_CMD}` 和每个已解析的 `{AGENT(...)}` 使用**相同**形式（`plugin` 或 `legacy`）——绝不在一个输出中混合。
- [ ] 在渲染的输出中没有 `# plugin form` / `# legacy form` 注释和“剥离前缀”的说明。
- [ ] 没有发明的 `--mode` / `--gate` / `--agents=...` 字段。
- [ ] 每个任务描述是单行、双引号括起，其中嵌入的 `