编排器流水线（共享引擎）
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。当 diff 触及安全触发器（见下文）时，添加security-reviewer。 - 6. 提交 — 常规提交（
feat:/fix:/refactor:/ ……），每个逻辑块一个提交。→ 门控 2。
两道门控
本家族是门控的，非自动的：
- 门控 1 — 计划后。 展示
task_list；在用户批准之前不编写实现代码。 - 门控 2 — 提交前。 展示 diff 摘要和提议的提交信息；在用户确认之前不提交。
两道门控之间的流程不间断执行。
智能体/命令映射
| 阶段 | 主要 | 备用/升级 |
|---|---|---|
| 输入/理解 | 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）。
安全审查触发器
当 diff 触及以下任一内容时引入 security-reviewer：认证或授权、用户输入处理、数据库查询、文件系统路径、外部 API 调用、加密、或密钥/凭证。（依据 rules/common/security.md。）
交接产物
流水线不携带隐藏状态——规划文档就是交接物：
task_list（来自计划阶段）驱动实现循环。- 较大工作还可能根据
rules/common/development-workflow.md，在仓库的docs/下输出 PRD / 架构 / 系统设计文档。 - 审查发现（CRITICAL / HIGH）必须在门控 2 之前解决。
验证
- 规模层级已声明并与工作匹配
- 门控 1（计划）和门控 2（提交）均已遵守
security-reviewer仅在触及安全触发器时运行- 提交采用约定式提交规范，并限定于单一逻辑变更
- 新/变更行为有测试；覆盖率 ≥ 80%（依据
rules/common/testing.md）