• — 必填；支持相对或绝对路径（接受@docs/...格式）。
• --lang— 代码审查语言变体；默认值为auto（从项目中检测）。
• --scope— 限制生成的步骤；默认为all。
• --dry-run— 仅打印分解 + 链式推理依据；不输出最终提示。

权威的/orchestrate格式（请勿偏离）

{ORCH_CMD} custom ",,...," ""

其中{ORCH_CMD}在第 0 阶段确定（见下文）。发出的输出中的命令字符串始终采用一种具体形式——绝不同时使用两种形式，也绝不使用占位符。

• custom是一个顺序链；每个代理的 HANDOFF 会传递给下一个。
• 以逗号分隔的代理列表。建议不使用空格；允许出现一个空格。
• 不存在--mode/--gate/--agents=...这些标志——切勿自行添加。
• 代理名称取自该技能的目录。任务描述中嵌入的双引号将转义为\"。

ECC 安装形式与命名空间

两种安装形式决定了斜杠命令及每个代理名称的前缀。这两种形式必须保持同步——每种输出对应一种形式，切勿混用：

设 表示 Claude Code 的主目录：macOS/Linux 系统下为~/.claude，Windows 系统下为%USERPROFILE%\.claude。请按照主机平台解析用户主目录的方式进行解析（切勿硬编码~）。

为何这很重要：在插件安装模式下，代理会注册为everything-claude-code:tdd-guide。仅使用名称会导致模糊匹配，而在并行调用时会间歇性地失败。在传统模式下，带前缀的形式不会被注册，因此会直接失败。

可用代理目录（必须从以下选项中选择）

通用：

• 规划器— 需求重述、风险分解、步骤规划
• architect— 架构、系统设计、重构建议
• tdd-guide— 编写测试 → 实现 → 80%+ 代码覆盖率
• 代码审查员— 通用代码审查
• 安全审查员— 安全审计、OWASP、机密泄露
• 重构清理员— 死代码、重复代码、knip类清理
• 文档更新员— 文档、代码映射、README
• docs-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 模式 + 编程语言

1. 读取 。若缺失或为空，则报告并终止。

2. 检测一次 ECC 安装形式，并将其固定为ECC_MODE。算法（按顺序执行，首次匹配即停止）：

   1. 如果存在/plugins/marketplaces/everything-claude-code/→ECC_MODE=plugin。
   2. 否则，如果/agents/存在且包含至少一个 ECC 代理文件（例如tdd-guide.md、code-reviewer.md）→ECC_MODE=legacy。
   3. 否则 → 默认设置为ECC_MODE=legacy，并在输出顶部显示一行警告：> 警告：无法检测到 ECC 安装；默认采用旧版形式。如果您使用插件安装，请手动编辑前缀。
   4. 如果两种标记都存在（混合安装），则以插件设置为准——只有插件命名空间会在解析代理名称时不进行模糊匹配。

   从这一刻起，每行输出中，斜杠命令和所有代理名称均使用匹配的前缀。同一输出中绝不会同时出现两种形式。

3. 解析--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/、生成的文件以及明显的测试 fixture）。 若出现平局，或没有一种语言的源文件占比超过 60%，则将lang 设为unknown。
   • 无标记匹配 → 设置lang=unknown。
   • lang=unknown是一个哨兵值——它不是代理名称。在第二阶段的规则 4 和 5 中，它会在构建链组合时被转换为代码审查者/构建错误解决者。

4. 检测PyTorch 子配置文件：当lang=python且pyproject.toml/requirements.txt/uv.lock中的任意文件声明了对torch 的依赖时，将pytorch 设为 true。这仅影响构建链的选择（见下文第二阶段规则）；代码审查者仍保持为python-reviewer。

5. 规范化计划中声明的任何代理名称：如果计划文本以带有插件前缀的形式引用代理（例如everything-claude-code:tdd-guide），则在验证或组合链之前，去除前缀以获取原始目录名称。 根据ECC_MODE（第 4 阶段），仅在输出时才会重新添加前缀。切勿让已添加前缀的名称流入链组合过程——这会在插件模式下导致前缀重复。

第 1 阶段 — 分解步骤

按优先级顺序识别“步骤单元”：

1. 显式编号：## 第 N 步/### 第 N 阶段/## N. .../ 顶级有序列表。
2. 表格中的“步骤”列。
3. ----以动词开头的标题分隔的块。
4. 否则将每个H2视为一个步骤。

针对每个步骤提取ID（从1开始）、标题（≤80个字符）、意图（1–3句话）和标签。

第 2 阶段 — 标签与链式筛选

按意图进行标注（允许多标签；标签链由主标签 + 堆叠的次级标签构成）：

以下触发词匹配不区分大小写。多语言方案通过匹配任何语言的词干来支持，只要其含义与列出的英文触发词一致即可。

链式组合规则：

1. 主标签选择：当某一步匹配多个标签时，按表中顺序排在最前面的那个（表首 = 最高优先级）为主标签；其余为次要标签。下文的组合规则 2 和 3 明确处理特定的多标签组合；否则，按标签表中的顺序追加次要链。
2. impl+security→tdd-guide,-reviewer,security-reviewer.
3. impl+db→tdd-guide,database-reviewer,-reviewer。
4. 对生成的链进行去重（保留首次出现的结果）。例如，review+lang=unknown根据规则 5 会生成code-reviewer,code-reviewer；去重后将其合并为code-reviewer。
5. 当 lang=unknown 时，-reviewer解析为code-reviewer。
6. 当 lang=unknown 时，- build -resolver解析为build-error-resolver。特殊情况：如果第 0 阶段设置了pytorch=true，则无论 。不存在python-build-resolver；当--lang=python且pytorch=true未设置时，将解析为build-error-resolver。
7. 零标签步骤：如果没有触发词匹配，则将链设置为code-reviewer并写入“未匹配任何标签”；在“链理由”下默认使用仅审查链。
8. 去重后链长度 ≤ 4。若超出，则舍弃最弱的标签（优先舍弃“lookup”和“docs”）。
9. 不要在实现链中将规划师和架构师配对（浪费令牌）。仅在设计步骤中将它们配对。
10. 标记为impl、refactor 或migration的步骤以reviewer 类代理结尾——即-reviewer、code-reviewer、security-reviewer 或database-reviewer 中的任意一个。 最符合领域特性的审阅者将占据末尾位置（例如：规则 2 的impl+security以security-reviewer 结束；规则 3 的impl+db以-reviewer结束，因为database-reviewer已在链条更早阶段对 migration 进行了门控）。测试和 构建步骤由各自的验证器（分别是e2e-runner和构建解析器）进行门控，无需额外的审核员。

第三阶段 — 压缩任务描述

每个生成的 必须：

• 自成体系（第一个代理无需打开计划文档）。
• 以[Plan:#step-] 开头。
• 包含 1–3 条可验证的验收标准。
• 仅当计划为此步骤声明了范围限制（范围外：...）时，才包含该限制。应原样继承。如果计划中没有范围外声明，则完全省略该子句——切勿自行添加。
• 长度为 200–600 个字符；仅占一行；转义字符 "需用\ 表示；不得包含字面换行符。

第 4 阶段 — 输出

使用由ECC_MODE确定的格式输出 Markdown。 输出应始终采用统一格式——每个{ORCH_CMD}和每个代理名称均应使用第 0 阶段对应的前缀进行渲染。请勿同时输出两种形式；请勿在渲染后的输出中包含“这是插件形式”或“去除前缀”等说明。

具体渲染规则：

• {ORCH_CMD}=插件模式下为/everything-claude-code:orchestrate ，旧版模式下为/orchestrate。
• {AGENT(name)}= 在插件模式下为everything-claude-code:， 在旧版中。
• 概览表中的“Chain”列采用相同的{AGENT(name)}渲染方式。
• 每步的 bash 代码块仅包含可执行的命令。不包含# plugin 形式或# legacy 形式的注释——该形式是隐含的，并在整个输出中保持统一。

输出结构：

#Plan-Orchestrate 结果

**计划**：``
**语言**：``
**ECC 模式**：``
**步骤**：
**范围**：

## 步骤概览

| # | 标题 | 标签 | 链 |
|---|---|---|---|
| 1 | ... | 实现, 数据库 | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## 步骤 1 —