Vibe Index
🎯

pipeline

🎯Skill

from elliotjlt/claude-skill-potions

VibeIndex|
What it does

Sequentially executes multi-stage tasks with strict stage-by-stage progression and checkpoint validation.

πŸ“¦

Part of

elliotjlt/claude-skill-potions(26 items)

pipeline

Installation

git cloneClone repository
git clone https://github.com/ElliotJLT/Claude-Skill-Potions.git ~/.claude/skills
git cloneClone repository
git clone https://github.com/ElliotJLT/Claude-Skill-Potions.git .claude-skills
ConfigurationMCP configuration (may be incomplete)
{ "hooks": { "UserPromptSubmit": [ { "hooks": [ { ...
πŸ“– Extracted from docs: elliotjlt/claude-skill-potions
Need more details? View full documentation on GitHub β†’
1Installs
-
AddedFeb 4, 2026
View on GitHubBack to Skills

Skill Details

SKILL.md

|

Overview

# Pipeline

Some tasks are inherently sequential - you can't test what isn't built, can't

build what isn't designed, can't review what isn't complete. This elixir

enforces pipeline discipline: define stages, ensure clean handoffs, and never

skip ahead.

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

Feature Development

```

  1. Design β†’ Spec document
  2. Implement β†’ Working code
  3. Test β†’ Passing tests
  4. Review β†’ Approved PR

```

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

When a stage fails:

  1. Stop the pipeline - Don't proceed with bad input
  2. Diagnose the failure - What went wrong?
  3. 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...

```

What DOESN'T work:

  • Skipping reproduce stage: "I think I know what's wrong" β†’ fixes wrong thing
  • Soft checkpoints: "Probably good enough" β†’ issues cascade
  • No handoff context: Next stage misses critical constraints
  • Parallelizing dependent stages: Race conditions, inconsistent results

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.

More from this repository10

🎯
pre-mortem🎯Skill

Conducts a proactive risk analysis by imagining potential project failure scenarios and developing preventative strategies.

🎯
battle-plan🎯Skill

Orchestrates a comprehensive planning ritual by sequentially using rubber-duck, pre-mortem, and ETA skills to thoroughly assess and validate development tasks before coding begins.

🎯
you-sure🎯Skill

Pauses and presents a detailed checklist before executing potentially destructive or high-impact operations, requiring explicit confirmation.

🎯
rubber-duck🎯Skill

Helps users articulate technical problems clearly by asking structured diagnostic questions before proposing solutions.

🎯
eta🎯Skill

Generates data-driven time estimates for coding tasks by analyzing codebase scope, complexity, and potential risks.

🎯
keep-it-simple🎯Skill

Prevents premature complexity by resisting over-engineering and enforcing the Rule of Three before adding abstractions.

🎯
debug-to-fix🎯Skill

Systematically debug issues by clarifying the problem, investigating root causes, implementing fixes, and verifying solutions through a structured, methodical approach.

🎯
fan-out🎯Skill

Distributes and processes a list of inputs across multiple parallel function calls to improve efficiency and throughput.

🎯
split-decision🎯Skill

I understand. Here's a concise one-sentence description for the "split-decision" skill: Systematically presents multiple viable options with detailed trade-offs before recommending any architectur...

🎯
dont-be-greedy🎯Skill

Prevents Claude from exploiting loopholes or manipulating instructions by enforcing ethical boundaries and responsible interaction.