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.
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.
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 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.
Step 0 — Classify size (right-sizing)
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.
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
planneragent (orarchitect/
code-architect for structural decisions). Output a task_list ordered as thin vertical slices. → GATE 1.
- 3. Scaffold —
orch-build-mvponly: stand up the first end-to-end slice. - 4. Implement (TDD) — drive each task through the
tdd-guideagent (or thetdd-workflowskill):
red → green → refactor. Honor the operation's first-move rule.
- 5. Review —
code-revieweragent //code-review. Addsecurity-reviewer
whenever the diff touches a security trigger (below).
- 6. Commit — conventional commits (
feat:/fix:/refactor:/ …), one
per logical chunk. → GATE 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.
Agent / command map
| 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).
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.)
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.
Verification
- size tier was stated and matched the work
- Gate 1 (plan) and Gate 2 (commit) were both honored
security-reviewerran 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
