| name | orch-pipeline |
| description | orch-* 技能家族的共享编排引擎。定义门控 Research-Plan-TDD-Review-Commit 流水线、规模分类器、智能体映射，以及 orch-* 操作技能委派到的两个人工门控。通常不直接调用。 |
| metadata | {"origin":"ECC"} |
Orchestrator Pipeline（共享引擎）
orch-* skills 都是薄包装。它们不重新实现任何工作，而是对请求分类，选择运行此流水线的哪些阶段，并把每个阶段委派给已有 ECC 智能体或命令。这个文件就是那条流水线。
直接调用操作技能（orch-add-feature、orch-fix-defect 等），不要直接调用此引擎。这个文件是它们指向的参考。
何时使用
- 每当
orch-* 操作技能运行时被间接加载。
- 只有在向该家族添加新操作，或调整共享阶段、门控、智能体映射时才直接阅读。
操作家族
| 技能 | 操作 | 触发 | 第一步 |
|---|
orch-add-feature | feature | 能力尚不存在 | research + plan a new slice |
orch-change-feature | tweak | 能工作，但期望行为不同 | 修改现有行为及其测试 |
orch-fix-defect | fix | 坏了；行为错误 | 复现为失败测试，然后修复 |
orch-refine-code | refactor | 行为不变，结构改进 | 在保持测试绿色的同时重构 |
orch-build-mvp | mvp | 从设计/规格文档引导 | ingest doc → vertical slices |
这些包装命令组合已有 ECC 命令，而不是替代它们：
/feature-dev、/plan、/code-review、/build-fix、/refactor-clean 和
/gan-build，以及 tdd-workflow 技能。orch-* 家族在它们之上增加共享规模分类器和两个门控，让五类操作由一个伞形流程一致覆盖。
Step 0 — 分类规模（right-sizing）
流程重量按影响范围缩放。对三个信号评分，取任何信号达到的最高层级，并用一句话说明结果，方便用户覆盖：
| 层级 | 触及文件 | 新依赖 / contract | 设计模糊度 | 运行阶段 |
|---|
| trivial | 1 个文件，几行 | 无 | 无——变更显而易见 | 4 → 5 → 6 |
| small | 1 个文件 / 1 个函数 | 无 | 读完代码后清楚 | (1 light) → 4 → 5 → 6 |
| standard | 2–5 个文件 | 可能有新内部模块 | 有一个真实选择要做 | 1 → 2 → 4 → 5 → 6 |
| large | 多文件 / 横切 | 新外部依赖、公共 API 或规格文档 | 多个开放问题 | 1 → 2 → (3) → 4 → 5 → 6 |
Phase 0（Intake）始终运行，因此在上面 mask 列中省略。平局规则：任何触及安全触发器（见下方）或公共 API / contract 的工作，至少是 standard，不管文件数多少。
阶段
每个阶段都委派出去，不在线内完成工作。
- 0. Intake — 重述请求。对
orch-build-mvp，读取 spec/design doc 并提取范围、锁定决策和功能列表。
- 1. Research & Reuse — 按
rules/common/development-workflow.md：gh search repos / gh search code，然后 Context7 / vendor docs，再 package registries，最后 Exa。优先采用已验证实现，而不是净新增代码。
- 2. Plan — 委派给
planner 智能体（结构决策用 architect / code-architect）。输出按薄垂直切片排序的 task_list。→ GATE 1.
- 3. Scaffold — 仅
orch-build-mvp：搭起第一个端到端切片。
- 4. Implement (TDD) — 通过
tdd-guide 智能体（或 tdd-workflow 技能）驱动每个任务：red → green → refactor。遵守该操作的 first-move 规则。
- 5. Review —
code-reviewer 智能体 / /code-review。diff 触及安全触发器（下方）时加入 security-reviewer。
- 6. Commit — conventional commits（
feat: / fix: / refactor: / …），每个 logical chunk 一个。→ GATE 2.
两个门控
该家族是门控的，不是自治的：
- GATE 1 — Plan 之后。 展示
task_list；用户批准前不要写实现代码。
- GATE 2 — Commit 之前。 展示 diff summary 和拟定 commit messages；用户确认前不要提交。
两个门控之间的流程不中断。
智能体 / 命令映射
| 阶段 | 主选 | 回退 / 升级 |
|---|
| Intake / understand | code-explorer | tweak、fix 或 refactor 前追踪现有路径 |
| Plan | planner | 结构调用用 architect、code-architect |
| Implement | tdd-guide（或 tdd-workflow 技能） | 构建失败用 build-error-resolver / /build-fix |
| Review | code-reviewer / /code-review | 语言审查器（python-reviewer、typescript-reviewer 等） |
| Security | security-reviewer | — |
| MVP inner loop | /gan-build "<brief>" --skip-planner | 驱动 gan-generator → gan-evaluator；调节 --max-iterations / --pass-threshold |
根据仓库自己的 CLAUDE.md 匹配语言审查器。
Security-review 触发器
当 diff 触及以下任何内容时拉入 security-reviewer：authentication 或 authorization、用户输入处理、database queries、file-system paths、external API calls、cryptography、secrets / credentials。（按 rules/common/security.md。）
交接产物
流水线不携带隐藏状态——规划文档本身就是交接：
task_list（来自 Plan）驱动 Implement 循环。- 更大的工作也可能按
rules/common/development-workflow.md 在仓库 docs/ 下产出 PRD / architecture / system_design。
- Review findings（CRITICAL / HIGH）必须在 Gate 2 前解决。
验证
- 已说明 size tier，且匹配工作量
- Gate 1（plan）和 Gate 2（commit）都被遵守
- 当且仅当触及安全触发器时运行
security-reviewer
- commits 是 conventional 且每个只覆盖一个 logical change
- 新增 / 变更行为有测试；按
rules/common/testing.md 覆盖率 ≥ 80%
