PromptsEdge
FreeGitHubResearch

Shared Orchestration Pipeline

Your AI runs the gated Research-Plan-TDD-Review-Commit pipeline used by orch-* skills. It classifies task size, delegates phases to agents, and manages human approval gates for feature addition, fixes, changes, and refactors.

affaan-m on GitHub

Curated by PromptsEdge from a public repo · MIT license. All credit goes to the author.

What is this skill?

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.

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

Invoke an operation skill (orch-add-feature, orch-fix-defect, …) rather than this engine directly. This file is the reference they point at.

The operation family

SkillOperationTriggerFirst move
orch-add-featurefeaturecapability does not exist yetresearch + plan a new slice
orch-change-featuretweakworks, but desired behavior differsamend existing behavior and its tests
orch-fix-defectfixbroken; behavior is wrongreproduce as a failing test, then fix
orch-refine-coderefactorbehavior stays, structure improvesrestructure while keeping tests green
orch-build-mvpmvpbootstrap from a design/spec docingest 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:

TierFiles touchedNew dependency / contractDesign ambiguityPhases that run
trivial1, a few linesnonenone — the change is obvious4 → 5 → 6
small1 file / 1 functionnoneclear once you read the code(1 light) → 4 → 5 → 6
standard2–5 filesmaybe a new internal moduleone real choice to make1 → 2 → 4 → 5 → 6
largemany / cross-cuttingnew external dep, public API, or a spec docmultiple open questions1 → 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:

  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

PhasePrimaryFallback / escalation
Intake / understandcode-explorertrace existing paths before a tweak, fix, or refactor
Planplannerarchitect, code-architect for structural calls
Implementtdd-guide (or tdd-workflow skill)build-error-resolver / /build-fix on build breaks
Reviewcode-reviewer / /code-reviewlanguage reviewer (python-reviewer, typescript-reviewer, …)
Securitysecurity-reviewer—
MVP inner loop/gan-build "<brief>" --skip-plannerdrives 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

Related skills

View all →