tools-only Pipeline
When To Activate
Trigger when:
- Task has natural phases that must happen in order
- Output of one stage is input to the next
- Skipping stages would cause problems
- User describes multi-phase work ("first X, then Y, then Z")
- Work involves: plan → implement → verify pattern
Do NOT trigger for:
- Independent tasks (use fan-out instead)
- Single-stage work
- Exploratory work with no clear sequence
The Pattern
[Input] → [Stage 1] → [Handoff] → [Stage 2] → [Handoff] → [Stage 3] → [Output]
│ │ │
└── Checkpoint ──────────┴── Checkpoint ──────────┘
Instructions
Step 1: Define the Pipeline
Map out all stages:
Pipeline: [Task Name]
Stages:
1. [Stage Name] - [What happens] - [Output artifact]
2. [Stage Name] - [What happens] - [Output artifact]
3. [Stage Name] - [What happens] - [Output artifact]
Dependencies:
- Stage 2 requires: [Stage 1 output]
- Stage 3 requires: [Stage 2 output]
Step 2: Define Checkpoints
Each stage needs exit criteria:
Stage 1 checkpoint:
- [ ] [Exit criterion 1]
- [ ] [Exit criterion 2]
- [ ] Artifact produced: [what]
Stage 2 checkpoint:
- [ ] [Exit criterion 1]
- [ ] Receives: [Stage 1 artifact]
- [ ] Artifact produced: [what]
Step 3: Execute Stage by Stage
For each stage:
═══════════════════════════════════════
STAGE [N]: [Name]
═══════════════════════════════════════
Input: [What this stage receives]
[Execute stage work]
Checkpoint:
- [✓/✗] Criterion 1
- [✓/✗] Criterion 2
Output: [What this stage produces]
[If all criteria pass] → Proceed to Stage N+1
[If any criterion fails] → Stop and resolve
Step 4: Handoff Protocol
Between stages, explicit handoff:
──────────────────────────────────────
HANDOFF: Stage [N] → Stage [N+1]
──────────────────────────────────────
Passing:
- [Artifact 1]: [description]
- [Artifact 2]: [description]
Context for next stage:
- [Key decision made]
- [Constraint to maintain]
- [Risk to watch for]
──────────────────────────────────────
Step 5: Pipeline Completion
When all stages complete:
═══════════════════════════════════════
PIPELINE COMPLETE: [Task Name]
═══════════════════════════════════════
Stages completed: [N/N]
Final output:
[Description of what was produced]
Artifacts:
- [Final deliverable 1]
- [Final deliverable 2]
Summary:
- Stage 1: [Brief outcome]
- Stage 2: [Brief outcome]
- Stage 3: [Brief outcome]
Common Pipeline Templates
Bug Fix
1. Reproduce → Consistent repro steps
2. Diagnose → Root cause identified
3. Fix → Code change
4. Verify → Bug no longer occurs
Refactoring
1. Assess → Impact analysis
2. Prepare → Tests in place
3. Refactor → Code changed
4. Validate → Tests still pass
Documentation
1. Outline → Structure defined
2. Draft → Content written
3. Review → Feedback incorporated
4. Publish → Live documentation
Handling Stage Failures
- Stop the pipeline - Don't proceed with bad input
- Diagnose the failure - What went wrong?
- Options:
- Fix and retry current stage
- Roll back to previous stage
- Abort pipeline with partial results
STAGE FAILURE: [Stage Name]
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Failed criterion: [What didn't pass]
Reason: [Why it failed]
Options:
A) Retry after fixing [specific issue]
B) Roll back to [previous stage]
C) Abort - partial output available
Recommendation: [A/B/C] because [reason]
NEVER
- Skip stages, even when "obvious" they'll pass
- Proceed without explicit checkpoint verification
- Let failures cascade to later stages
- Lose context between stages (use handoff protocol)
- Run stages in parallel (use fan-out for that)
ALWAYS
- Define all stages before starting
- Verify checkpoint criteria explicitly
- Document handoffs with context
- Stop on stage failure
- Report pipeline status at completion
Examples
Example 1: Feature Implementation
User: "Add password reset functionality"
Pipeline: Password Reset Feature
Stages:
1. Design → Security spec, API contract
2. Implement → Endpoint, email service, token handling
3. Test → Unit tests, integration tests
4. Review → Security review, code review
═══════════════════════════════════════
STAGE 1: Design
═══════════════════════════════════════
[Produces security spec covering token expiry,
rate limiting, email verification]
Checkpoint:
- [✓] Security requirements defined
- [✓] API contract specified
- [✓] Edge cases documented
Output: Design spec
──────────────────────────────────────
HANDOFF: Design → Implement
──────────────────────────────────────
Passing: Design spec
Context: Tokens expire in 1 hour, max 3 attempts/hour
═══════════════════════════════════════
STAGE 2: Implement
═══════════════════════════════════════
[Implements based on spec]
...continues through all stages...
Example 2: Debugging Pipeline
User: "Users are seeing 500 errors on checkout"
Pipeline: Checkout 500 Error Fix
Stages:
1. Reproduce → Consistent repro steps
2. Diagnose → Root cause found
3. Fix → Code change
4. Verify → Error resolved
═══════════════════════════════════════
STAGE 1: Reproduce
═══════════════════════════════════════
Attempting to reproduce...
Checkpoint:
- [✓] Error reproduced locally
- [✓] Consistent reproduction steps documented
Output: Repro steps - 500 occurs when cart has
item with null price field
──────────────────────────────────────
HANDOFF: Reproduce → Diagnose
──────────────────────────────────────
Passing: Repro steps
Context: Only occurs with specific data condition
...continues...
Why This Elixir Exists
Sequential work needs sequential discipline. The temptation is to skip ahead - "I'll just start coding and figure out the design as I go." This leads to rework, bugs, and frustration.
Pipelines force the discipline: complete each stage before moving on. It feels slower but is faster in total time because you don't backtrack.
The checkpoint isn't bureaucracy - it's the moment where you catch problems before they become expensive.