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

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.

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:

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 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.

The two gates

This family is gated, not autonomous:

1. GATE 1 — after Plan. Present the task_list; do not write implementation code until the user approves.
2. 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

…