Frontmatter

name: orch-pipeline
description: Shared orchestration engine for the orch-* skill family. Defines the gated Research-Plan-TDD-Review-Commit pipeline, the size classifier, the agent map, and the two human gates that the orch-* operation skills delegate to. Not usually invoked directly.
metadata:
  origin: ECC

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