Menu
orch-* 技能家族的共享编排引擎。定义门控 Research-Plan-TDD-Review-Commit 流水线、规模分类器、智能体映射，以及 orch-* 操作技能委派到的两个人工门控。通常不直接调用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
| name | orch-pipeline |
| description | orch-* 技能家族的共享编排引擎。定义门控 Research-Plan-TDD-Review-Commit 流水线、规模分类器、智能体映射，以及 orch-* 操作技能委派到的两个人工门控。通常不直接调用。 |
| metadata | {"origin":"ECC"} |
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-* 家族在它们之上增加共享规模分类器和两个门控，让五类操作由一个伞形流程一致覆盖。
流程重量按影响范围缩放。对三个信号评分，取任何信号达到的最高层级，并用一句话说明结果，方便用户覆盖：
| 层级 | 触及文件 | 新依赖 / 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，不管文件数多少。
每个阶段都委派出去，不在线内完成工作。
orch-build-mvp，读取 spec/design doc 并提取范围、锁定决策和功能列表。rules/common/development-workflow.md：gh search repos / gh search code，然后 Context7 / vendor docs，再 package registries，最后 Exa。优先采用已验证实现，而不是净新增代码。planner 智能体（结构决策用 architect / code-architect）。输出按薄垂直切片排序的 task_list。→ GATE 1.orch-build-mvp：搭起第一个端到端切片。tdd-guide 智能体（或 tdd-workflow 技能）驱动每个任务：red → green → refactor。遵守该操作的 first-move 规则。code-reviewer 智能体 / /code-review。diff 触及安全触发器（下方）时加入 security-reviewer。feat: / fix: / refactor: / …），每个 logical chunk 一个。→ GATE 2.该家族是门控的，不是自治的：
task_list；用户批准前不要写实现代码。两个门控之间的流程不中断。
| 阶段 | 主选 | 回退 / 升级 |
|---|---|---|
| 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 匹配语言审查器。
当 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。security-reviewerrules/common/testing.md 覆盖率 ≥ 80%Kubernetes 工作负载模式、资源管理、RBAC、probes、autoscaling、ConfigMap/Secret 处理，以及面向生产级部署的 kubectl 调试。
完成任何非平凡任务后使用。智能体按 5 个维度自评输出——准确性、完整性、清晰度、可执行性、简洁性——每项都给出具体证据。生成结构化 1-5 评分卡和具体改进建议。
在 competitive-platform-analysis 产出分层竞品集合后使用。按九个加权维度（定位、声音、视觉工艺、offer packaging、证据、enterprise-readiness、thought leadership、定价、客户 strategic tension）为每个竞品评分，使用明确 1–5 rubrics 和 tension-plot。位于 competitive-report-structure 之前。
当品牌需要通过结构化多会话访谈发现或表达身份时使用。通过 laddering、5 Whys 和 projective techniques，覆盖目的、定位、受众、个性、声音、叙事以及 founder-brand 张力 8 个模块。产出可恢复 session、磁盘持久化状态和 master brandbook（90_SYNTHESIS.md）。
通过 CodeScene MCP 提供实时结构性 Code Health——编辑前审查，变更后验证分数变化，门控 commit 和 PR。用于代码质量审查、重构、检查 AI 变更是否降低文件质量，或 commit/PR 前。
用于界定竞争 landscape：在任何 benchmark 开始前，识别、分类并用分数过滤竞品集合。决定谁算竞品、属于哪个 tier、应挖哪些来源。三技能竞争分析流水线第一步；位于 benchmark-methodology 之前。