orch-pipeline

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.

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

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