orch-pipeline

Name: orch-pipeline
Author: affaan-m

Coordinates the orch skill family with gated research-to-commit workflows.

Stars

★ 243,958

Source

GitHub

Updated

2026-08-28

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 244.0k

Running security audit…

Credentials
Network egress
Code execution
Data access
Supply chain

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "orch-pipeline" skill from askskill:
1. Download https://raw.githubusercontent.com/affaan-m/ECC/main/skills/orch-pipeline/SKILL.md
2. Save it as ~/.claude/skills/orch-pipeline/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Orchestrate feature delivery

Prompt

Use orch-pipeline to set up a full workflow for “adding bulk export to the admin system”: do Research first, then produce a Plan, execute implementation and tests with TDD, enter Review, and finally provide Commit guidance, explicitly pausing at the two human approval gates.

Expected

A staged orchestration result with research findings, an execution plan, TDD steps, review checkpoints, and human approval stops before commit.

Classify task size and route agents

Prompt

Use orch-pipeline to analyze the task size for this request: “refactor the existing login module and add missing integration tests,” classify it as small, medium, or large, and recommend which sub-skills or agents should be involved based on the agent map.

Expected

A task size classification, the rationale behind it, and recommended execution paths with agent role assignments.

Pre-commit quality gates

Prompt

Use orch-pipeline to verify whether a development task is ready to enter Commit: confirm that Research, Plan, TDD, and Review are complete, list any missing items, and identify what requires human approval before proceeding.

Expected

A pre-commit gate check report showing current completeness, gaps, risks, and items awaiting human approval.

// docs

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.