Orchestrator Pipeline（共享引擎） 是做什么的？
orch-* 技能是薄包装器。它们不重新实现任何工作——它们对请求进行分类，选择此管道运行的阶段，并将每个阶段委托给现有的 ECC 代理或命令。此文件即为该管道。
请直接调用操作技能（
orch-add-feature、orch-fix-defect……），而不是直接使用此引擎。此文件是它们指向的参考。
何时使用
- 每当
orch-*操作技能运行时，间接加载。 - 仅在向家族添加新操作或调整共享阶段、门控或代理映射时直接阅读。
操作家族
| 技能 | 操作 | 触发条件 | 第一步 |
|---|---|---|---|
orch-add-feature | 功能 | 能力尚不存在 | 研究 + 规划新切片 |
orch-change-feature | 调整 | 功能存在但期望行为不同 | 修改现有行为及其测试 |
orch-fix-defect | 修复 | 损坏；行为错误 | 将缺陷重现为失败的测试，然后修复 |
orch-refine-code | 重构 | 行为不变，结构改善 | 重构，同时保持测试通过 |
orch-build-mvp | MVP | 从设计/规范文档启动 | 读取文档 → 垂直切片 |
这些包装器组合了现有的 ECC 命令而非替换它们：
/feature-dev、/plan、/code-review、/build-fix、/refactor-clean和/gan-build，以及tdd-workflow技能。orch-* 家族在此基础上添加了共享的 规模分类器和两个门控，因此一个统一的覆盖层可以始终如一地覆盖所有五种操作。
步骤 0 — 分类规模（合适规模）
流程复杂度应随影响范围缩放。根据以下三个信号对请求评分，取任何信号达到的最高层级，并在一行中陈述结果，以便用户可以覆盖：
| 层级 | 涉及文件数 | 新依赖/契约 | 设计模糊性 | 执行的阶段 |
|---|---|---|---|---|
| 微小 | 1个文件，几行 | 无 | 无 — 变更显而易见 | 4 → 5 → 6 |
| 小型 | 1个文件/1个函数 | 无 | 阅读代码即可明确 | (1 轻量) → 4 → 5 → 6 |
| 标准 | 2–5个文件 | 可能新增内部模块 | 存在一个实际需要做决定的问题 | 1 → 2 → 4 → 5 → 6 |
| 大型 | 多个/跨层 | 新的外部依赖、公共 API 或规范文档 | 多个待解决问题 | 1 → 2 → (3) → 4 → 5 → 6 |
阶段 0（接收）始终运行，在上面的掩码列中省略。打破平局规则：任何触及安全触发器（见下文）或公共 API / 契约的内容至少属于标准级，无论文件数多少。
各阶段
每个阶段都进行委托——不内联完成工作。
- 0. 接收 — 重述请求。对于
orch-build-mvp，读取规范/设计文档并提取范围、已锁定的决策和功能列表。 - 1. 研究与复用 — 根据
rules/common/development-workflow.md：gh search repos/gh search code，然后是 Context7 / 供应商文档，然后是包注册表，最后是 Exa。优先采用经过验证的实现而非全新代码。 - 2. 计划 — 委托给
planner代理（或architect/code-architect处理结构决策）。输出按薄垂直切片排序的task_list。→ 门控 1。 - 3. 脚手架 — 仅
orch-build-mvp：搭建第一个端到端切片。 - 4. 实现（TDD） — 通过
tdd-guide代理（或tdd-workflow技能）驱动每个任务： 红 → 绿 → 重构。遵守操作的第一步规则。 - 5. 审查 —
code-reviewer代理 //code-review。当差异触及安全触发器（见下文）时，添加security-reviewer。 - 6. 提交 — 符合约定的提交（
feat:/fix:/refactor:/ ……），每个逻辑块一个提交。→ 门控 2。
两个门控
此家族是门控的，而非自主运行：
- 门控 1 — 计划后。 呈现
task_list；在用户批准之前，不编写实现代码。 - 门控 2 — 提交前。 呈现差异摘要和建议的提交消息；在用户确认之前，不进行提交。
两个门控之间的流程持续进行，不会停止。
代理/命令映射
| 阶段 | 主要代理 | 备用/升级 |
|---|---|---|
| 接收/理解 | code-explorer | 在调整、修复或重构前追踪现有路径 |
| 计划 | planner | architect、code-architect 处理结构决策 |
| 实现 | tdd-guide（或 tdd-workflow 技能） | 构建失败时使用 build-error-resolver / /build-fix |
| 审查 | code-reviewer / /code-review | 语言审查者（python-reviewer、typescript-reviewer……） |
| 安全 | security-reviewer | — |
| MVP 内部循环 | /gan-build "<简要>" --skip-planner | 驱动 gan-generator → gan-evaluator；调整 --max-iterations / --pass-threshold |
根据仓库选择语言审查者（请参阅仓库自身的 CLAUDE.md）。
安全审查触发器
当差异涉及以下任何内容时，引入 security-reviewer：身份验证或授权、用户输入处理、数据库查询、文件系统路径、外部 API 调用、加密技术或密钥/凭据。（根据 rules/common/security.md。）
交接产物
管道不携带隐藏状态——规划文档就是交接物：
task_list（来自计划阶段）驱动实现循环。- 较大型的工作也可能在仓库
docs/目录下生成 PRD / 架构 / 系统设计文档，遵循rules/common/development-workflow.md。 - 审查发现（严重 / 高）必须在门控 2 之前解决。
验证
- 已说明规模层级，并且与实际工作匹配
- 门控 1（计划）和门控 2（提交）均已遵循
- 当且仅当触发了安全触发器时，
security-reviewer已运行 - 提交通常遵循约定，并限定于单个逻辑变更
- 新增/变更的行为有测试；覆盖率 ≥ 80%（根据
rules/common/testing.md）