pipeline

Pipeline

Alpha (v0.2.0-alpha) — This plugin is under active development. Commands, config keys, and behavior may change between releases. Feedback welcome.

A web-first agent workflow engine for Claude Code with 29 commands. A content-blind orchestrator routes stateless AI agents through a quality pipeline — from brainstorm to deploy — while standalone tools handle debugging, auditing, testing, and more. Agents read context from and write results to shared stores. First-class support for web and mobile development; adapted profiles for services, data pipelines, and automation.

A one-line fix gets committed in seconds. A new feature gets designed, debated, built, reviewed, and security-tested — automatically.

What Using It Looks Like

You fix a typo (TINY change)

You edit a string in one file. You type /pipeline:commit. Pipeline runs your type checker, linter, and tests. Everything passes. It commits and pushes. No decisions to make — it just works.

You add a feature to 2 files (MEDIUM change)

You implement the change. You type /pipeline:commit. Pipeline counts the source files you touched — it's under the review threshold, so it runs preflight gates and commits. If you'd touched 3 or more files (the default threshold), it would have blocked you:

BLOCKED — 3 source files changed. /pipeline:review is required before committing.
Run /pipeline:review, apply all fixes, then /pipeline:commit reviewed:✓

You can't talk your way past this. The gate is absolute.

You run /pipeline:review on your changes

Pipeline runs your typecheck, linter, and SAST scanner (semgrep with custom security rules, or grep fallback) on changed files, then reads every changed file in full and reviews against your configured criteria. If you're editing Pipeline itself, agent template lint checks your prompt templates for structural correctness. The output looks like this:

## Code Review

### Files reviewed
src/hooks/useAuth.ts
src/pages/Login.tsx
src/lib/api.ts

### Must fix
src/hooks/useAuth.ts:47 — unhandled promise rejection on token refresh [confidence: HIGH]
> refreshToken() can throw if the network is down, but the caller has no try/catch.
> The user sees a white screen instead of the login page.
> Fix: Wrap in try/catch, redirect to /login on failure.

### Should fix
src/lib/api.ts:12 — dead import [confidence: HIGH]
> `parseResponse` is imported but never used after the refactor in this diff.

### Verdict
Issues found — 1 thing that needs attention before shipping

Every finding has a severity (🔴 HIGH / 🟡 MEDIUM / 🔵 LOW), a confidence level, a file and line number, and a specific fix. No "looks good" — if the reviewer finds nothing, it must explain exactly what it checked and why each check passed.

You build a new feature (LARGE change)

You describe what you want. The orchestrator routes you through the full workflow. Your engagement style (expert/guided/full-guidance) controls question depth — an expert gets minimal questions, a newcomer gets thorough explanations at every step:

1. /pipeline:brainstorm — asks clarifying questions one at a time, proposes 2-3 approaches, writes a spec. Creates a GitHub feature epic if issue tracking is enabled.
2. /pipeline:debate — three parallel agents (Advocate, Skeptic, Practitioner) stress-test the spec from first principles. Produces constraints the plan must respect.
3. /pipeline:architect — parallel domain specialists assess your technology choices and produce decision records that constrain the build
4. /pipeline:plan — turns the spec into bite-sized tasks with architectural constraints, debate verdict, and a QA strategy. For LARGE/MILESTONE, generates a standalone QA test plan with work packages.
5. /pipeline:build — dispatches a fresh subagent for each task. Agents are stateless — they read their own context from stores (architecture plan, decisions, gotchas, GitHub issues, build state) rather than receiving pasted context. No accumulated context means quality doesn't degrade over a 15-task build. A reviewer agent checks each task before moving to the next.
6. /pipeline:qa verify — parallel QA workers execute the test plan, a seam pass verifies integration boundaries
7. /pipeline:review --since abc123 — runs SAST scanning (semgrep + custom security rules), agent template lint if prompt templates changed, then reviews everything built since the baseline commit
8. /pipeline:finish — merge, PR, compiled epic summary, dashboard update