<Purpose> Pipeline chains multiple droids together in sequential or branching workflows where the output of one droid becomes the input to the next. It creates powerful droid pipelines for structured, multi-phase tasks. </Purpose>

<Use_When>

•Task has clear sequential phases where each depends on the previous
•User says "pipeline", "stage", "chain", or describes a multi-phase workflow
•Work benefits from structured handoff between specialist droids
•Need to combine research, planning, implementation, and review in order </Use_When>

<Do_Not_Use_When>

•All tasks are independent -- use ultrawork for parallel execution
•Task needs persistence and retry -- use ralph
•Task is a single-step operation -- delegate directly to a droid </Do_Not_Use_When>

<Why_This_Exists> Complex tasks benefit from structured phases where specialist droids handle what they're best at. A researcher gathers context, a planner designs the approach, an executor implements, and a verifier checks. Pipeline ensures clean handoff between phases with full context passing. </Why_This_Exists>

<Pipeline_Presets>

Review Pipeline

code

/oh-my-droid-pipeline review <task>

Stages:

•explore - Find relevant code and patterns
•prometheus - Analyze and plan approach
•momus - Critique the plan
•executor-med - Implement with full context

Use for: Major features, refactorings, complex changes

Implement Pipeline

code

/oh-my-droid-pipeline implement <task>

Stages:

•prometheus - Create implementation plan
•executor-med - Implement the plan
•test-engineer - Add/verify tests
•verifier - Verify completion

Use for: New features with clear requirements

Debug Pipeline

code

/oh-my-droid-pipeline debug <issue>

Stages:

•explore - Locate error locations and related code
•oracle - Analyze root cause
•executor-med - Apply fixes
•verifier - Verify fix works

Use for: Bugs, build errors, test failures

Research Pipeline

code

/oh-my-droid-pipeline research <topic>

Stages:

•librarian - External docs and API research
•explorer - Internal codebase analysis
•prometheus - Synthesize findings into recommendations

Use for: Technology evaluation, architecture decisions

Security Pipeline

code

/oh-my-droid-pipeline security <scope>

Stages:

•security-auditor - Vulnerability scan
•code-reviewer - Code quality review
•executor-med - Fix critical issues
•verifier - Verify fixes

Use for: Security hardening, pre-release audits </Pipeline_Presets>

<Custom_Pipelines> Users can define custom pipelines by specifying stages:

code

/oh-my-droid-pipeline custom "Stage1: explore, Stage2: executor-med, Stage3: verifier" <task>

Branching Pipelines

Route to different droids based on output:

code

explore -> {
  if "complex refactoring" -> prometheus -> executor-high
  if "simple change" -> executor-low
  if "needs research" -> librarian -> executor-med
}

Parallel-Then-Merge

Run droids in parallel, merge outputs:

code

parallel(explore, librarian) -> prometheus -> executor-med

</Custom_Pipelines>

<Steps> 1. **Select preset** or parse custom pipeline definition 2. **Execute Stage 1**: Spawn first droid, collect output 3. **Pass context**: Feed Stage 1 output as context to Stage 2 4. **Repeat**: Continue through all stages with context accumulation 5. **Report**: Final summary with results from each stage </Steps>

<Output_Format>

Pipeline Results

Stage 1: [Droid] - [Status]

[Summary of output]

Stage 2: [Droid] - [Status]

[Summary of output]

Final Result

[Aggregated outcome] </Output_Format>

<Failure_Modes_To_Avoid>

•Lost context: Not passing previous stage output to next stage. Always include full context.
•Wrong preset: Using "debug" pipeline for a new feature. Match preset to task type.
•Skipping stages: Jumping from research to implementation without planning.
•No verification: Pipeline ends at implementation without a verification stage. </Failure_Modes_To_Avoid>