安装方式
命令行安装
在项目根目录执行以下命令，完成 Skill 安装。
npx bzskills add affaan-m/everything-claude-code --skill orch-pipeline
返回全部 Skills
orch-pipeline
开发工具
官方认证
共享编排引擎，用于 orch-* 技能家族。定义了门控的 Research-Plan-TDD-Review-Commit 流水线、规模分类器、代理映射以及两个人工门控，orch-* 操作技能会委托给这些门控。通常不直接调用。
29
下载量
skill.md
name: orch-pipeline
description: 共享编排引擎，用于 orch-* 技能家族。定义了门控的 Research-Plan-TDD-Review-Commit 流水线、规模分类器、代理映射以及两个人工门控，orch-* 操作技能会委托给这些门控。通常不直接调用。
metadata:
origin: ECC编排器流水线（共享引擎）
orch-* 类技能是薄包装层。它们不会重新实现任何工作——而是对请求进行分类，选择*此*流水线运行的哪些阶段，并将每个阶段委托给现有的 ECC 代理或命令。本文件即为该流水线。
请直接调用操作技能（例如orch-add-feature、orch-fix-defect……），而非直接调用此引擎。本文件是它们指向的参考。
何时使用
- 每当
orch-*操作技能运行时间接加载。 - 仅在新增操作家族成员或调整共享阶段、门控或代理映射时直接阅读。
操作家族
| 技能 | 操作 | 触发条件 | 第一步动作 |
|---|---|---|---|
orch-add-feature | feature | 能力尚不存在 | 研究 + 规划新切片 |
orch-change-feature | tweak | 功能正常，但期望行为不同 | 修改现有行为*及其测试* |
orch-fix-defect | fix | 损坏；行为错误 | 复现为失败测试，然后修复 |
orch-refine-code | refactor | 行为不变，结构改进 | 重构结构，同时保持测试通过 |
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/目录下依据rules/common/development-workflow.md发布 PRD / 架构 / 系统设计文档。 - 审查发现（CRITICAL / HIGH）必须在门控 2 之前解决。
验证
- 已声明规模层级并与工作匹配
- 门控 1（规划）和门控 2（提交）均已遵循
security-reviewer仅在触及安全触发器时运行- 提交为约定式，且限于一个逻辑变更
- 新增/变更的行为有测试；覆盖率 ≥ 80%，依据
rules/common/testing.md