A closed-loop development pipeline built as Claude Code slash commands. Spec → Plan → Implement → Audit → Fix → Merge — fully orchestrated, with artifact traceability at every phase.
PipelineIQ is a collection of Claude Code slash commands (markdown prompt files) that automate the full development lifecycle. A natural-language description of a feature is taken through structured planning, code generation in an isolated git worktree, independent auditing against the original spec, automated error correction, and a clean fast-forward merge — producing timestamped artifacts at each step.
There is no build step, no runtime, and no dependencies. The deliverables are markdown files in commands/
that Claude Code executes as slash commands.
From English description to merged code. Each phase is a specialized subagent with a focused scope and isolated context.
A separate agent — with no knowledge of the plan — verifies the implementation against the original spec.
Audit errors feed into an automated fix loop (up to 2 cycles). Process friction is logged for continuous improvement.
Install via the Claude Code plugin system (recommended) or manually copy the command files. The pipeline validates that all reference files are present at startup.
Artifact directories (specs/, Implementation Plans/,
Working Logs/) are created automatically in the main repo root, never inside worktrees.
All artifacts are gitignored.
Each command can be invoked standalone or is called internally by the pipeline orchestrator.
| Command | Purpose | Input | Output |
|---|---|---|---|
| /pipeline | Run the full 6-phase pipeline for a single feature | Description or spec path | Merged code + all artifacts |
| /pipeline-team | Run multiple specs in parallel with dependency-aware scheduling | Pre-written specs in specs/team/ |
Batch summary + per-spec artifacts |
| /spec | Interactive spec generation via structured interview | Feature description | specs/spec--*.md |
| /impl-plan | Create a step-by-step implementation plan + worktree | Spec file | Implementation Plans/impl--*.md |
| /impl | Execute a plan: write code, run tests, log results | Implementation plan | Working Logs/wlog--*.md |
| /audit-implementation | Independent verification of implementation vs. spec | Working log | Working Logs/audit-impl--*.md |
| /fix | Address actionable errors found by the auditor | Audit report | Working Logs/fixer-log--*.md |
| /spec-splitter | Decompose a large spec into parallelizable child specs | Spec file | N child specs in specs/team/ |
/pipeline "add feature X" orchestrates all six phases.
Each phase runs as a subagent with its own reference prompt template, and produces a timestamped artifact that feeds the next phase.
Runs an interactive interview covering goals, trade-offs, edge cases, constraints, and testing strategy. Produces a structured specification document. Can also accept an existing spec file to skip this phase.
A planning agent reads the spec and the current codebase, then writes a self-contained implementation plan: files to touch, code for each change, verification checklist, and a draft commit message. Creates a git worktree on a dedicated branch for isolated work.
Follows the plan step-by-step inside the worktree: writes code, runs build/lint/test after each step, and retries failures (up to 3 attempts per step). Every change, error, and deviation is logged.
A fresh, independent agent that has never seen the plan or working log reads the original spec and inspects the codebase directly. Verifies each goal, categorizes failures (spec drift, incomplete tasks, build/test failures, rule violations), and produces a numbered list of actionable errors for the fix phase.
If the audit found actionable errors, a fix agent parses the error list, applies targeted fixes, and re-runs tests. A re-audit then verifies the fixes. This loop runs up to 2 cycles; decreasing error counts indicate progress. Errors requiring human judgment are flagged and skipped.
The worktree is rebased onto main and merged with --ff-only (guaranteeing linear history).
A summary of all artifacts and remaining errors is produced. Process observations are appended to
learnings.md — a continuously growing record of pipeline friction and suggested improvements.
The worktree and its branch are then cleaned up.
All artifacts are timestamped markdown files stored in the main repo root (never inside worktrees). Each artifact references its predecessors, forming a traceable chain from requirement to merged code.
specs/spec--*.md
Structured requirements: Goal, Decisions, Technical Design, Edge Cases, Constraints, Testing Strategy.
Moves to specs/applied/ once planning begins.
Implementation Plans/impl--*.md
Step-by-step build instructions: files to touch, code to write, verification checklist, draft commit message.
Self-contained — the implementer agent needs nothing else.
Working Logs/wlog--*.md
Execution record: every file change, error encountered (with retry counts), deviation from plan, and verification results.
Working Logs/audit-impl--*.md
Independent verdict on spec compliance. Contains categorized failures, actionable errors with suggested fixes,
and proposed process improvements.
Working Logs/fixer-log--*.md
Records which audit errors were fixed, which were skipped (not actionable or requiring human judgment), and which failed.
learnings.md
Append-only process knowledge base. Tracks pipeline friction with severity tiers, occurrence counts, and
concrete improvement suggestions (including diffs).
specs/ is the inbox.
specs/applied/ is the archive (spec has been planned or split).
specs/team/ is the batch staging area (ready for /pipeline-team).
A spec moves to applied/ only after planning begins or after /spec-splitter generates child specs from it.
For multi-spec efforts, /pipeline-team orchestrates up to 5 concurrent pipelines
with automatic dependency detection, sequential merge ordering, and failure recovery.
/spec-splitter analyzes a large spec for complexity and, if warranted,
decomposes it into independent child specs with shared foundations. Dependencies are wired
via keyword embedding so /pipeline-team's automatic detection works correctly.
Keywords are extracted from spec titles (words > 4 chars, minus stopwords). Two or more matching keywords between specs creates a dependency edge. Cycles are detected and reported before execution begins.
| /pipeline | /pipeline-team | |
|---|---|---|
| Input | One spec (interactive or pre-written) | Multiple pre-written specs |
| Parallelism | Sequential phases | Up to 5 concurrent pipelines |
| Dependencies | N/A | Automatic keyword-based graph |
| Merge | Immediate rebase + ff-only | Sequential merge queue |
| Error handling | Fix loop (2 cycles) | Fix loop + repair agent + user escalation |
Key architectural decisions and the reasoning behind them.
The audit agent has never seen the plan or working log. It reads only the original spec and the current code. This prevents confirmation bias — it cannot be influenced by what the implementer intended.
Every implementation runs in a git worktree (a separate working directory on its own branch). The main branch is never modified until the explicit merge phase. Batch runs can have 5 worktrees active simultaneously.
Worktrees are rebased before merging with --ff-only.
This guarantees perfectly linear git history, making bisection and rollback straightforward.
Every pipeline run appends process observations to learnings.md, building a knowledge base
of recurring friction. Each entry includes the affected phase, occurrence count, and a concrete suggested fix with a diff.
Each pipeline phase has a reference file (commands/references/pipeline/phase*.md)
that serves as a prompt template with [VARIABLE] placeholders.
The orchestrator substitutes values before passing to subagents. These are not documentation.
All artifact directories exist only in the main repo root, never in worktrees.
Subagents use absolute [MASTER_REPO_PATH] paths.
This ensures every phase can find prior artifacts regardless of which worktree it runs in.
Every artifact references its predecessors. Any piece of code on main can be traced back to the spec decision that motivated it.