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

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
```
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:

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-reviewer
```
ran 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
```

orch-pipeline

NPX Install

Tags

SKILL.md Content