$ loading_
为 orch 系列技能统一编排研发流程与人工审批关卡
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "orch-pipeline" 技能： 1. 下载 https://raw.githubusercontent.com/affaan-m/ECC/main/skills/orch-pipeline/SKILL.md 2. 保存为 ~/.claude/skills/orch-pipeline/SKILL.md 3. 装好后重载技能，告诉我可以用了
请使用 orch-pipeline 为“给后台管理系统新增批量导出功能”建立完整流程：先做 Research，再输出 Plan，然后按 TDD 执行实现与测试，进入 Review，最后给出 Commit 建议，并在两个需要人工确认的关卡明确停下等待。
输出按阶段组织的任务编排结果，包含研究结论、实施计划、测试驱动步骤、评审检查点以及提交前的人工确认节点。
请用 orch-pipeline 分析这个需求的任务规模：‘重构现有登录模块并补齐集成测试’，判断属于小型、中型还是大型任务，并根据 agent map 建议应调用哪些子技能或代理参与。
给出任务规模判断、判断依据，以及适合的执行路径和代理分工建议。
请通过 orch-pipeline 检查一个开发任务在进入 Commit 前是否满足要求：确认 Research、Plan、TDD、Review 四个阶段是否完整，列出缺失项，并指出哪些内容需要人工审批后才能继续。
返回一份提交前门禁检查结果，说明当前完成度、缺口、风险点和待人工确认事项。
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-* operation skill runs.| 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 thetdd-workflowskill. The orch-* family adds the shared size classifier and the two gates on top of them, so one umbrella covers all five operations consistently.
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.
Each phase delegates — it does not do the work inline.
orch-build-mvp, read the spec/design
doc and extract scope, locked decisions, and a feature list.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.planner agent (or architect /
code-architect for structural decisions). Output a task_list ordered as
thin vertical slices. → GATE 1.orch-build-mvp only: stand up the first end-to-end slice.tdd-guide agent (or the tdd-workflow skill):
red → green → refactor. Honor the operation's first-move rule.code-reviewer agent / /code-review. Add security-reviewer
whenever the diff touches a security trigger (below).feat: / fix: / refactor: / …), one
per logical chunk. → GATE 2.This family is gated, not autonomous:
task_list; do not write implementation
code until the user approves.…
通过双评审智能体对结果进行对抗式校验，提升输出发布前的可靠性
帮助团队编排多代理协作流程，管理任务归属、看板流转与交接控制。