You type one command before bed. By morning, a written spec is waiting for you. So is the actual code, a full set of tests that already ran, and a clear SHIP, NEEDS WORK, or BLOCK verdict on the whole thing. All you do is review and merge. That is the entire idea behind a Claude Code agent pipeline, and once you set it up, it changes how you think about using AI to write software.
Most people who use AI to code are stuck in a different loop. You ask it to plan, it plans. You ask it to write the code, it writes the code. You ask it to test, it tests. Then you have to remember to ask for "one more thing," and somewhere in there you are still the one manually carrying context from step to step. You are still the bottleneck. The fix is not a smarter prompt. The fix is a pipeline: four specialist agents that hand off to each other automatically, triggered by a single command.
What Is a Skill File (and Why This Pipeline Needs One)?
If you have used Claude Code at all, you have probably typed a slash command like /clear or /compact. Custom slash commands let you save a repeated instruction as a file so you never have to retype it. In current versions of Claude Code, custom commands and skills work together: a skill is a folder containing a SKILL.md file with instructions, and typing /skill-name runs it, per the official Claude Code skills documentation. Anything you used to paste into chat by hand (a checklist, a multi-step procedure, a review process) can live in one of these files instead.
That is the building block this whole pipeline is made of. Instead of one skill file, we are going to write five: one for each of four specialist agents, plus one orchestrator that ties them together.
If you are brand new to Claude and want the basics first, start with How to Start Using Claude AI as a Complete Beginner before coming back to this.
The Problem With How Most People Use AI to Code
Picture the usual flow: you say "plan this," Claude plans it. You say "now write the code," it writes the code. You say "now test it," it tests it. Then you ask for "one more thing" and the cycle repeats. Every one of those hops is on you. You are the one deciding what happens next, copying context from one step into the next, and catching your own mistakes before they compound.
That works, but it does not scale past a few requests a day, and it means you cannot walk away. The moment you stop typing, the whole thing stops moving.
The Fix Is a Pipeline
A pipeline replaces that manual back-and-forth with four specialist agents that hand off to each other on their own:
- Plan – understands the request and creates a plan.
- Code – writes clean, working code from that plan.
- Test – tests everything thoroughly.
- Review – reviews, polishes, and gives a final verdict.
One command kicks the whole thing off. You wake up (or come back from lunch) to a finished, reviewed, tested feature. No babysitting, no copy-pasting context between agents, no manual work in between.
How the Handoff Actually Works
The trick that makes this reliable is dead simple: each agent writes its output to a shared folder, and the next agent reads that file to pick up exactly where the last one stopped. In practice that looks like a .pipeline/ folder with four files:
- Planner writes →
.pipeline/spec.md - Coder reads the spec, writes →
.pipeline/changes.md - Tester reads the changes, writes →
.pipeline/test-results.md - Reviewer reads everything, writes →
.pipeline/review.md
One folder, four files, zero confusion about what happened at each stage or who is responsible for what. If something goes wrong, you can open any one of those files and see exactly what that agent was working from and what it produced.
Agent 1: The Planner
Job: turn a vague idea into a clear, detailed spec. It never writes code.
The Planner's only responsibility is to read your codebase, understand how things are actually built, and then write a spec covering:
- Exactly which files need to change
- What functions are needed
- Edge cases to handle
- Any open questions if something is unclear
Think of it as the architect who draws the blueprint before anyone picks up a hammer. In Claude Code terms, this maps directly onto a custom subagent with a narrow, single-purpose job description and its own isolated context, so it is not distracted by implementation details.
Agent 2: The Coder
Job: build exactly what the spec says. Nothing more.
The Coder reads the Planner's spec, writes the actual code following the patterns already in your codebase, then writes a short summary of what it changed and why. It does not plan, and it does not review its own work. It just builds. Keeping this agent narrowly scoped is what stops "helpful" scope creep, where an AI agent quietly rewrites things you never asked it to touch.
Agent 3: The Tester
Job: prove that the code actually works.
The Tester reads what the Coder built and writes tests covering the normal use case, the edge cases the Planner flagged, and at least one failure case. Then it actually runs those tests. If anything fails, it stops and reports rather than trying to patch the code itself. One job, one output: find problems, report them, move on.
Agent 4: The Reviewer
Job: the final gate before anything reaches your codebase.
The Reviewer reads the spec, the changes, and the test results, runs a diff to see exactly what changed, and gives one of three verdicts:
- SHIP – it's ready
- NEEDS WORK – here's exactly what to fix
- BLOCK – do not merge this
Important: the Reviewer can only read. It cannot edit code. If it sees a problem, it flags it, and fixing it is your job (or the Coder's, on the next pass). That read-only constraint matters. It keeps a single agent from both writing code and grading its own homework.
The One Command That Runs All Four
Once you have all four agent configuration files, you wrap them in a single orchestrator, commonly saved as a project skill (for example .claude/skills/ship/SKILL.md, which is what /ship invokes). Type something like:
/ship add rate limiting to the login endpoint
That is it. The orchestrator sends your request to the Planner, waits for the spec, sends the spec to the Coder, waits for the code, sends the changes to the Tester, waits for the test results, sends everything to the Reviewer, and shows you the final verdict. One line in, four agents run in sequence, one full feature out.
This is the same pattern described in Anthropic's own docs on creating custom subagents and running agents in parallel or in sequence: specialized workers with their own context, chained together by an orchestrating instruction set. If you want to go further and fan work out across many subagents at once instead of one at a time, that same documentation page covers dynamic workflows.
What You Wake Up To
You typed one command before bed. By morning you have a written spec of what was planned, the actual code written, tests written and run, and a SHIP, NEEDS WORK, or BLOCK verdict waiting for you. You just do the final review and merge. The pipeline did everything else.
This is the shift that matters. You stop being the one who manually connects "plan" to "code" to "test" to "review." You become the person who reviews finished work and decides what ships.
Where to Start
If you are already comfortable with Claude AI Projects for organizing context, the next step up is exactly this: giving Claude a repeatable, multi-step process it can run without you in the loop. And if your team wants agents talking to your own tools and data instead of just your codebase, look at how to connect Claude AI to your apps using the Claude API as a companion piece to this setup.
One personal note: the first time a /ship command handed me back a finished, tested feature with a clear verdict waiting for me, it genuinely changed how I plan my day. I stopped scheduling coding time around "when I'm free to babysit the AI" and started scheduling it around "when I review what already got done." If you have been putting off learning how these workflows fit together, How to Learn Claude AI Automation as a Complete Beginner is the right place to build up from. And before you go all-in on a heavier model or workflow like this one, it is worth running through 5 Steps to Audit Your Claude AI Setup first, so you know your current setup is actually the right foundation to build a pipeline on top of.
Download the Free Claude Code 4-Agent Pipeline Kit
Download includes:
ship.md: the orchestrator skill/command that runs the full pipeline in sequenceplanner.md: the Planner agent configurationcode.md: the Coder agent configurationtester.md: the Tester agent configurationreviewer.md: the Reviewer agent configuration
Copy these five files into your project's .claude/skills/ (or .claude/commands/ and .claude/agents/), adjust the file paths and constraints to match your own codebase, and you have your own /ship command ready to go.
