orch-pipeline

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Orchestrator Pipeline (shared engine)

编排器流程（共享引擎）

The

orch-*

skills are thin wrappers. They do not re-implement any work — they classify the request, choose which phases of this pipeline run, and delegate each phase to an existing ECC agent or command. This file is that pipeline.

Invoke an operation skill (
orch-add-feature
,
orch-fix-defect
, …) rather than this engine directly. This file is the reference they point at.

orch-*

系列技能是轻量封装层，它们不会重新实现任何工作——而是对请求进行分类，选择本流程中需要运行的阶段，并将每个阶段委托给已有的ECC Agent或命令。本文件就是该核心流程。

请调用操作类技能（
orch-add-feature
、
orch-fix-defect
等），而非直接调用本引擎。本文件是这些技能指向的参考实现。

When to Use

使用场景

Loaded indirectly whenever an
```
orch-*
```
operation skill runs.
Read directly only when adding a new operation to the family or tuning the shared phases, gates, or agent map.

每当
```
orch-*
```
操作类技能运行时，会间接加载本引擎。
仅当为该家族添加新操作，或调整共享阶段、审核门或Agent映射时，才需要直接阅读本文件。

The operation family

操作技能家族

Skill	Operation	Trigger	First move
`orch-add-feature`	feature	capability does not exist yet	research + plan a new slice
`orch-change-feature`	tweak	works, but desired behavior differs	amend existing behavior and its tests
`orch-fix-defect`	fix	broken; behavior is wrong	reproduce as a failing test, then fix
`orch-refine-code`	refactor	behavior stays, structure improves	restructure while keeping tests green
`orch-build-mvp`	mvp	bootstrap from a design/spec doc	ingest doc → vertical slices

These wrappers compose existing ECC commands rather than replace them:
/feature-dev
,
/plan
,
/code-review
,
/build-fix
,
/refactor-clean
, and
/gan-build
, plus the
tdd-workflow
skill. The orch-* family adds the shared size classifier and the two gates on top of them, so one umbrella covers all five operations consistently.

技能	操作类型	触发条件	初始动作
`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
以及
tdd-workflow
技能。orch-*家族在这些基础上添加了共享规模分类器和两个审核门，从而让五种操作能保持一致的执行逻辑。

Step 0 — Classify size (right-sizing)

步骤0——规模分类（合理适配）

Ceremony scales to blast radius. Score the request on three signals, take the highest tier any signal reaches, and state the result in one line so the user can override:

Tier	Files touched	New dependency / contract	Design ambiguity	Phases that run
trivial	1, a few lines	none	none — the change is obvious	4 → 5 → 6
small	1 file / 1 function	none	clear once you read the code	(1 light) → 4 → 5 → 6
standard	2–5 files	maybe a new internal module	one real choice to make	1 → 2 → 4 → 5 → 6
large	many / cross-cutting	new external dep, public API, or a spec doc	multiple open questions	1 → 2 → (3) → 4 → 5 → 6

Phase 0 (Intake) always runs and is omitted from the mask column above. The tie-breaker: anything touching a security trigger (below) or a public API / contract is at least standard, regardless of file count.

流程复杂度与影响范围成正比。基于三个信号对请求评分，取任意信号达到的最高等级，并将结果用一句话告知用户以便其覆盖调整：

等级	涉及文件数	新增依赖/契约	设计模糊度	运行阶段
trivial	1个文件，少量代码	无	无——修改逻辑明确	4 → 5 → 6
small	1个文件/1个函数	无	阅读代码后逻辑清晰	（简化版1）→4→5→6
standard	2–5个文件	可能新增内部模块	存在一个实际决策点	1→2→4→5→6
large	大量文件/跨模块	新增外部依赖、公开API或规格文档	存在多个未明确问题	1→2→(3)→4→5→6

阶段0（需求接收）始终运行，因此未在上述阶段列中体现。优先级判定规则：任何涉及安全触发点（如下文所述）或公开API/契约的修改，至少归为standard等级，无论文件数量多少。

The phases

流程阶段

Each phase delegates — it does not do the work inline.

0. Intake — restate the request. For
```
orch-build-mvp
```
, read the spec/design doc and extract scope, locked decisions, and a feature list.
1. Research & Reuse — per
```
rules/common/development-workflow.md
```
:
```
gh search repos
```
/
```
gh search code
```
, then Context7 / vendor docs, then package registries, then Exa. Prefer adopting a proven implementation over net-new code.
2. Plan — delegate to the
```
planner
```
agent (or
```
architect
```
/
```
code-architect
```
for structural decisions). Output a
```
task_list
```
ordered as thin vertical slices. → GATE 1.
3. Scaffold —
```
orch-build-mvp
```
only: stand up the first end-to-end slice.
4. Implement (TDD) — drive each task through the
```
tdd-guide
```
agent (or the
```
tdd-workflow
```
skill): red → green → refactor. Honor the operation's first-move rule.
5. Review —
```
code-reviewer
```
agent /
```
/code-review
```
. Add
```
security-reviewer
```
whenever the diff touches a security trigger (below).
6. Commit — conventional commits (
```
feat:
```
/
```
fix:
```
/
```
refactor:
```
/ …), one per logical chunk. → GATE 2.

每个阶段仅负责委托任务——不会在线执行实际工作。

0. 需求接收——重述请求内容。对于
```
orch-build-mvp
```
，需读取规格/设计文档并提取范围、已确定决策和功能列表。
1. 调研与复用——遵循
```
rules/common/development-workflow.md
```
：执行
```
gh search repos
```
/
```
gh search code
```
，然后查询Context7/供应商文档，再到包注册中心，最后使用Exa。优先采用已验证的实现而非从零开发。
2. 规划——委托给
```
planner
```
Agent（若涉及架构决策则委托给
```
architect
```
/
```
code-architect
```
）。输出按轻量垂直模块排序的
```
task_list
```
。→ 审核门1
3. 脚手架搭建——仅
```
orch-build-mvp
```
使用：搭建首个端到端功能模块。
4. 实现（TDD）——通过
```
tdd-guide
```
Agent（或
```
tdd-workflow
```
技能）推进每个任务：红→绿→重构。遵循对应操作的初始动作规则。
5. 评审——由
```
code-reviewer
```
Agent/
```
/code-review
```
执行。若代码变更涉及安全触发点（如下文所述），需添加
```
security-reviewer
```
参与评审。
6. 提交——使用conventional commits（
```
feat:
```
/
```
fix:
```
/
```
refactor:
```
/…），每个提交对应一个逻辑单元。→ 审核门2

The two gates

两个审核门

This family is gated, not autonomous:

GATE 1 — after Plan. Present the
```
task_list
```
; do not write implementation code until the user approves.
GATE 2 — before Commit. Present the diff summary and proposed messages; do not commit until the user confirms.

Everything between the gates flows without stopping.

本家族采用审核驱动而非完全自主的模式：

审核门1——规划阶段后：展示
```
task_list
```
，需获得用户批准后才可编写实现代码。
审核门2——提交阶段前：展示代码变更摘要和拟提交信息，需获得用户确认后才可提交。

两个审核门之间的流程会自动连续执行。

Agent / command map

Agent/命令映射

Phase	Primary	Fallback / escalation
Intake / understand	`code-explorer`	trace existing paths before a tweak, fix, or refactor
Plan	`planner`	`architect` , `code-architect` for structural calls
Implement	`tdd-guide` (or `tdd-workflow` skill)	`build-error-resolver` / `/build-fix` on build breaks
Review	`code-reviewer` / `/code-review`	language reviewer ( `python-reviewer` , `typescript-reviewer` , …)
Security	`security-reviewer`	—
MVP inner loop	`/gan-build "<brief>" --skip-planner`	drives `gan-generator` → `gan-evaluator` ; tune `--max-iterations` / `--pass-threshold`

Match the language reviewer to the repo (see the repo's own

CLAUDE.md

阶段	首选角色	备选/升级角色
需求接收/理解	`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 "<brief>" --skip-planner`	驱动 `gan-generator` → `gan-evaluator` ；可调整 `--max-iterations` / `--pass-threshold` 参数

需根据仓库匹配对应语言评审员（参考仓库自身的

CLAUDE.md

）。

Security-review trigger

安全评审触发条件

Pull in

security-reviewer

when the diff touches any of: authentication or authorization, user-input handling, database queries, file-system paths, external API calls, cryptography, or secrets / credentials. (Per

rules/common/security.md

当代码变更涉及以下任一内容时，需引入

security-reviewer

：认证/授权、用户输入处理、数据库查询、文件系统路径、外部API调用、加密技术或密钥/凭证。（遵循

rules/common/security.md

）

Handoff artifacts

交接产物

The pipeline carries no hidden state — the planning docs are the handoff:

```
task_list
```
(from Plan) drives the Implement loop.
Larger work may also emit PRD / architecture / system_design under the repo's
```
docs/
```
per
```
rules/common/development-workflow.md
```
.
Review findings (CRITICAL / HIGH) must be resolved before Gate 2.

流程不携带隐藏状态——规划文档即为交接依据：

```
task_list
```
（来自规划阶段）驱动实现环节。
大型任务可能还会在仓库
```
docs/
```
目录下生成PRD/架构/系统设计文档，遵循
```
rules/common/development-workflow.md
```
。
评审发现的CRITICAL/HIGH级问题必须在审核门2前解决。

Verification

验证标准

size tier was stated and matched the work
Gate 1 (plan) and Gate 2 (commit) were both honored
```
security-reviewer
```
ran iff a security trigger was touched
commits are conventional and scoped to one logical change
new / changed behavior has tests; coverage ≥ 80% per
```
rules/common/testing.md
```

规模等级已明确且与实际工作匹配
审核门1（规划）和审核门2（提交）均已执行
涉及安全触发点时已调用
```
security-reviewer
```
提交信息符合规范且每个提交对应一个逻辑变更
新增/修改的行为有测试用例；测试覆盖率≥80%，遵循
```
rules/common/testing.md
```