orch-pipeline

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.

两个门控

该家族是门控的，不是自治的：

1. GATE 1 — Plan 之后。 展示 task_list；用户批准前不要写实现代码。
2. 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%