I Built a 4-Agent Claude Code Pipeline That Ships Code While I Sleep

---

title: I Built a 4-Agent Claude Code Pipeline That Ships Code While I Sleep

published: true

tags: claudeai, ai, productivity, tutorial

canonical_url: https://coding180.com/claude-code-4-agent-pipeline

---

# I Built a 4-Agent Claude Code Pipeline That Ships Code While I Sleep

You type one command before bed. By morning: a written spec, the actual code, tests that already ran, and a SHIP, NEEDS WORK, or BLOCK verdict waiting for you. That's the whole idea behind a Claude Code agent pipeline, and once it's running it changes how you think about using AI to write software.

The Loop Most People Get Stuck In

You ask Claude to plan, it plans. You ask it to write the code, it writes the code. You ask it to test, it tests. Somewhere in there you're still the one carrying context from step to step, still the one deciding what happens next. The moment you stop typing, the whole thing stops moving. That's not a prompting problem, it's an architecture problem. The fix is four specialist agents that hand off to each other automatically, triggered by one command.

The Handoff: A Shared Folder, Not a Shared Context Window

The part that makes this actually reliable is simple. Each agent writes its output to a file in a `.pipeline/` folder, and the next agent reads that file to pick up exactly where the last one stopped.

.pipeline/spec.md          <- Planner writes
.pipeline/changes.md       <- Coder writes
.pipeline/test-results.md  <- Tester writes
.pipeline/review.md        <- Reviewer writes

One folder, four files. If something breaks, you open any one of them and see exactly what that agent had to work with.

The Four Agents

Each one is a Claude Code [subagent](https://code.claude.com/docs/en/sub-agents): a narrow job, its own isolated context, one output.

**Planner** never writes code. It reads the codebase, understands how things are actually built, and writes a spec: which files change, what functions are needed, edge cases, open questions.

**Coder** reads that spec and builds exactly what it says, following the patterns already in the codebase. Keeping it scoped this tightly is what stops the "helpful" scope creep where an agent quietly rewrites things you never asked it to touch.

**Tester** reads what the Coder built and writes tests for the normal case, the edge cases the Planner flagged, and at least one failure case, then actually runs them. If something fails, it stops and reports rather than trying to patch the code itself.

**Reviewer** is the final gate. It reads the spec, the changes, and the test results, runs a diff, and gives one of three verdicts: SHIP, NEEDS WORK, or BLOCK. It's read-only by design. It can flag a problem but not fix it, which keeps one agent from writing code and grading its own homework.

Wiring It to One Command

Wrap all four in an orchestrator, saved as a project skill (`.claude/skills/ship/SKILL.md`). Then type:

/ship add rate limiting to the login endpoint