How to build a 4-agent team that ships a feature while you sleep
A local Claude Code pipeline chains four subagents (planner → coder → tester → reviewer) via handoff files under `.pipeline/`, all triggered by a single `/ship` slash command. The Planner writes an implementation spec; the Coder builds to it and outputs a changes summary; the Tester writes and runs tests, stopping on failure without patching code; the Reviewer is read-only and issues a SHIP / NEEDS WORK / BLOCK verdict. The setup is copy-paste ready. A brief mention of the Teamly platform shows a similar orchestration model, but the core value is the handoff architecture you can run locally.
Four AI agents can ship a feature while you sleep. Most people never wire them up.
They fire a reviewer here, a test generator there, by hand, one at a time, each forgetting what the last one did. You're still the bottleneck.
The fix: Planner → Coder → Tester → Reviewer, chained to hand off automatically. One trigger, four stages, a finished feature by morning.
Here's the full pipeline, with copy-paste code 👇
Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: https://t.me/zodchixquant 🧠
四个 AI 智能体能在你睡觉时交付一个功能。但大多数人从未把它们串联起来。
他们手动在这里触发一个审阅者，在那里触发一个测试生成器，各自为战，每次调用都忘了上一个做了什么——你仍然是瓶颈。
解决办法：Planner → Coder → Tester → Reviewer，链式流转、自动交接。一次触发，四个阶段，第二天早上一个完整功能就位。
以下是完整流水线，附带可直接复制粘贴的代码 👇
在深入之前，我在电报频道分享关于 AI 和 vibe coding 的每日笔记：https://t.me/zodchixquant 🧠
Why a pipeline beats a pile of agents
One agent doing everything fills its context window with planning, code, tests, and review notes until quality drops.
Four specialists each stay in a clean, narrow context.
The trick is the handoff file. Each agent writes its output where the next one can read it: Planner drops a spec at .pipeline/spec.md, Coder reads it and writes .pipeline/changes.md, and so on.
The orchestrator running them in order is a single slash command. That's the whole thing: four subagents, one command, a shared folder for handoffs.
为什么流水线优于一堆各自为战的智能体
单个智能体处理所有事情，其上下文窗口会被规划、代码、测试和审查笔记填满，直到质量下降。
四个专门化的智能体各自保持干净、狭窄的上下文。
关键在于交接文件（handoff file）。每个智能体将其输出写到下一个智能体可以读取的位置：Planner 把规格说明写到 .pipeline/spec.md，Coder 读取它并写入 .pipeline/changes.md，以此类推。
按顺序运行它们的编排器只是一个斜杠命令。就这么简单：四个子智能体，一个命令，一个共享的交接文件夹。
Agent 1: The Planner (subagent, opus)
The Planner never writes code. It turns a vague feature request into a concrete spec the Coder can follow without guessing.
Create .claude/agents/planner.md:
---
name: planner
description: Turns a feature request into an implementation spec. Use as the first stage of the feature pipeline.
tools: Read, Grep, Glob, Write
model: opus
---
You are a planning specialist. You do NOT write implementation code.
Given a feature request:
1. Read the relevant parts of the codebase to understand current patterns.
2. Write a spec to `.pipeline/spec.md` containing:
- Files to create or modify, with exact paths
- The interface or function signatures needed
- Edge cases the implementation must handle
- Which existing patterns to follow (name the file to copy from)
3. Flag anything ambiguous as an OPEN QUESTION at the top of the spec.
Keep the spec tight. The Coder reads this and nothing else, so leave
no gaps and invent no requirements that weren't asked for.
Planning runs on opus because this stage sets the quality ceiling for everything after it. A vague spec produces vague code no matter how good the Coder is.
智能体 1：Planner（子智能体，opus）
Planner 从不写代码。它把模糊的功能请求转化为具体的规格说明，让 Coder 无需猜测就能执行。
创建 .claude/agents/planner.md：
---
name: planner
description: 将功能请求转化为实现规格说明。用作功能流水线的第一阶段。
tools: Read, Grep, Glob, Write
model: opus
---
你是一名规划专家。你不写实现代码。
给定一个功能请求：
1. 阅读代码库的相关部分，了解当前模式。
2. 将规格说明写入 `.pipeline/spec.md`，包含：
- 要创建或修改的文件及其确切的路径
- 所需的接口或函数签名
- 实现必须处理的边界情况
- 要遵循的现有模式（指明要复制的文件）
3. 将任何模糊不清的内容标记为 OPEN QUESTION，放在规格说明顶部。
保持规格说明紧凑。Coder 只读取这个文件，别无其他，所以不要留下空白，也不要编造需求之外的要求。
规划阶段运行在 opus 上，因为这一阶段为之后的一切设定了质量上限。无论 Coder 多么优秀，模糊的规格说明都会产生模糊的代码。
Agent 2: The Coder (subagent, sonnet)
The Coder reads the spec and writes the implementation. It doesn't plan and it doesn't review its own work, it just builds what the spec says.
Create .claude/agents/coder.md:
---
name: coder
description: Implements the spec at .pipeline/spec.md. Use as the second stage of the feature pipeline, after the planner.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
You are an implementation specialist.
1. Read `.pipeline/spec.md` in full. If it has OPEN QUESTIONS, stop and
surface them instead of guessing.
2. Implement exactly what the spec describes. Follow the patterns it
names. Do not add features it didn't ask for.
3. Write a short summary to `.pipeline/changes.md`: which files changed,
what each change does, and anything the Tester should focus on.
You write code that matches the repo. You do not refactor unrelated
code or "improve" things outside the spec's scope.
Sonnet is the right call here: implementation against a clear spec is exactly the balanced cost-quality work Sonnet handles best.
The handoff note at .pipeline/changes.md is what lets the Tester target the right surface instead of testing blind.
智能体 2：Coder（子智能体，sonnet）
Coder 读取规格说明并编写实现代码。它不做规划，也不审查自己的成果，只是按照规格说明来构建。
创建 .claude/agents/coder.md：
---
name: coder
description: 实现 `.pipeline/spec.md` 中的规格说明。用作功能流水线的第二阶段（在 planner 之后）。
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
你是一名实现专家。
1. 完整读取 `.pipeline/spec.md`。如果其中有 OPEN QUESTIONS，则停止并展示它们，而不是自行猜测。
2. 精确实现规格说明描述的内容。遵循其中指明的模式。不要添加规格说明未要求的特性。
3. 将简短总结写入 `.pipeline/changes.md`：哪些文件发生了变更，每个变更的作用，以及 Tester 应重点关注的内容。
你编写的代码要与代码库匹配。不要重构不相关的代码，也不要改进规格说明范围之外的东西。
这里选择 Sonnet 是合适的：针对清晰的规格说明进行实现，正是 Sonnet 处理得最好的那种成本与质量平衡的工作。
pipeline/changes.md 中的交接注记让 Tester 能够精准定位测试范围，而不是盲目测试。
Agent 3: The Tester (subagent, sonnet)
The Tester reads what changed and writes tests that prove the feature works, then runs them.
Create .claude/agents/tester.md:
---
name: tester
description: Writes and runs tests for changes described in .pipeline/changes.md. Third stage of the feature pipeline.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
You are a test specialist.
1. Read `.pipeline/changes.md` to see what was built and where.
2. Read the changed files and the spec at `.pipeline/spec.md`.
3. Write tests covering: the happy path, the edge cases the spec named,
and at least one failure case. Match the repo's test framework.
4. Run the tests. If any fail, write the failures to
`.pipeline/test-results.md` and STOP. Do not fix the code yourself.
5. If all pass, note that in `.pipeline/test-results.md`.
You test behavior, not implementation details. A failing test means
the pipeline pauses for the Reviewer, not that you patch around it.
智能体 3：Tester（子智能体，sonnet）
Tester 读取变更内容，编写验证功能正常工作的测试，然后运行它们。
创建 .claude/agents/tester.md：
---
name: tester
description: 为 `.pipeline/changes.md` 中描述的变更编写并运行测试。功能流水线的第三阶段。
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---
你是一名测试专家。
1. 读取 `.pipeline/changes.md`，了解构建了什么以及在哪里。
2. 读取变更的文件和 `.pipeline/spec.md` 中的规格说明。
3. 编写覆盖以下方面的测试：正常路径、规格说明中指明的边界情况，以及至少一个失败情况。与代码库的测试框架保持一致。
4. 运行测试。如果有任何失败，将失败信息写入 `.pipeline/test-results.md` 并停止。不要自己修复代码。
5. 如果全部通过，在 `.pipeline/test-results.md` 中注明。
你测试的是行为，而不是实现细节。测试失败意味着流水线暂停，等待 Reviewer 处理，而不是让你绕过问题打补丁。
Agent 4: The Reviewer (subagent, opus)
The last gate. The Reviewer reads everything the pipeline produced and gives a verdict before any of it reaches your main branch.
Create .claude/agents/reviewer.md:
---
name: reviewer
description: Final review of the full pipeline output. Fourth and last stage before human sign-off.
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior reviewer. You are read-only. You do not edit code.
1. Read the spec, the changes summary, and the test results from
`.pipeline/`.
2. Run `git diff` to see the actual changes.
3. Assess: does the code match the spec? Are the tests meaningful or
superficial? Any security, performance, or correctness issues?
4. Write a verdict to `.pipeline/review.md`:
- VERDICT: SHIP / NEEDS WORK / BLOCK
- For NEEDS WORK or BLOCK, list exactly what to fix and where.
Be the last line of defense. If the tests are green but the code is
wrong, say BLOCK. Green tests are not the same as correct behavior.
Read-only tools mean the Reviewer can't paper over problems by editing, it can only judge.
智能体 4：Reviewer（子智能体，opus）
最后一道关卡。Reviewer 读取流水线产生的所有内容，并在任何内容进入你的主分支之前给出裁决。
创建 .claude/agents/reviewer.md：
---
name: reviewer
description: 对流水线完整输出进行最终审查。人工签署前的第四阶段也是最后阶段。
tools: Read, Grep, Glob, Bash
model: opus
---
你是一名资深审查者。你只读。你不编辑代码。
1. 从 `.pipeline/` 读取规格说明、变更摘要和测试结果。
2. 运行 `git diff` 查看实际变更。
3. 评估：代码是否符合规格说明？测试是有意义的还是表面的？是否存在安全、性能或正确性问题？
4. 将裁决写入 `.pipeline/review.md`：
- VERDICT: SHIP / NEEDS WORK / BLOCK
- 对于 NEEDS WORK 或 BLOCK，精确列出需要修复什么以及在何处修复。
作为最后一道防线。如果测试是绿的但代码是错误的，说 BLOCK。绿色测试不等于正确行为。
只读工具意味着 Reviewer 无法通过编辑来掩盖问题，它只能判断。
The orchestrator: one command to run all four
Now the piece that turns four separate agents into a pipeline. A slash command that invokes them in order, each one picking up the handoff file the last one wrote.
Create .claude/commands/ship.md:
Run the full feature pipeline for: $ARGUMENTS
Execute these stages in order. Do not skip ahead. After each stage,
confirm the handoff file exists before starting the next.
1. Delegate to the `planner` subagent with the feature request above.
Wait for `.pipeline/spec.md`.
2. If the spec has OPEN QUESTIONS, stop and show them to me. Otherwise
delegate to the `coder` subagent. Wait for `.pipeline/changes.md`.
3. Delegate to the `tester` subagent. Wait for `.pipeline/test-results.md`.
If tests failed, stop and show me the failures.
4. Delegate to the `reviewer` subagent. Show me `.pipeline/review.md`.
Report the final verdict. Do not merge anything. Leave the branch for
my morning review.
Then a single line kicks off the whole chain: /ship add rate limiting to the login endpoint.
编排器：一个命令运行全部四个
现在，将四个独立的智能体转变为一个流水线的关键部分。一个按顺序调用它们的斜杠命令，每个智能体拾取上一个写入的交接文件。
创建 .claude/commands/ship.md：
为 $ARGUMENTS 运行完整的功能流水线
按顺序执行这些阶段。不要跳过。在每个阶段之后，确认交接文件存在后再开始下一个。
1. 将上述功能请求委派给 `planner` 子智能体。等待 `.pipeline/spec.md`。
2. 如果规格说明有 OPEN QUESTIONS，停止并向我展示。否则委派给 `coder` 子智能体。等待 `.pipeline/changes.md`。
3. 委派给 `tester` 子智能体。等待 `.pipeline/test-results.md`。如果测试失败，停止并向我展示失败信息。
4. 委派给 `reviewer` 子智能体。向我展示 `.pipeline/review.md`。
报告最终裁决。不要合并任何内容。保留分支供我早上审查。
然后一行命令就能启动整个链条：/ship add rate limiting to the login endpoint。
Where I run the overnight version
That's what I use Teamly for: managed cloud hosting built specifically for AI agents.
You hire a team, it runs 24/7 on dedicated infrastructure, and you never touch a server.
The reason @Teamly fits this article specifically: the handoff problem is already solved for you.
Everything we built by hand above (the spec file, the changes file, the orchestrator chaining one agent to the next) Teamly does with a Coordinator.
It routes work between agents, passes context from one to the next, and keeps a shared brief they all read from.
The same Planner-to-Coder-to-Tester flow, except you don't wire the handoffs yourself.
The difference is that @Teamly isn't code-only. The exact same orchestration runs a marketing team, a research team, or a support team.
Your Claude Code pipeline ships features overnight; a Teamly marketing team ships content the same way, with the same hand-off logic underneath.
我在哪里运行夜间版本
我就是为此使用 Teamly 的：专为 AI 智能体构建的托管云服务。
你雇佣一个团队，它在专用基础设施上 7×24 小时运行，你无需触碰任何服务器。
@Teamly 特别贴合本文的原因：它已经为你解决了交接问题。
上面我们手工构建的所有东西（规格文件、变更文件、将智能体串联起来的编排器），Teamly 通过一个 Coordinator 来完成。
它在智能体之间路由工作，将上下文从一个传递给下一个，并维护一个大家都读取的共享简报。
同样的 Planner → Coder → Tester 流程，只不过你不需要自己编写交接逻辑。
不同之处在于 @Teamly 不仅仅是面向代码的。完全相同的编排逻辑也可以运行营销团队、研究团队或支持团队。
你的 Claude Code 流水线在夜间交付功能；Teamly 的营销团队以同样的方式交付内容，底层使用相同的交接逻辑。
Build the exact team you need
New feature, that team just rolled out: My Team
Now you can build your team with just 3 questions.
You also can control: voice rules, forbidden phrases, integrations, team style (Strict / Casual / Creative), and team size (2-4 agents).
@Teamly returns a team with a real rationale for why each specialist is there, not boilerplate. Swap any agent with one click. Edit the brief if it's off.
The point is a structured brief that forces clarity, then composes a team you can audit before hiring.
Same handoff architecture as the pre-built teams, fitted to your specific problem.
构建你需要的精确团队
新功能刚刚推出：My Team。
现在你只需回答 3 个问题就能构建你的团队。
你还可以控制：语音规则、禁用短语、集成、团队风格（严格 / 随意 / 创意）以及团队规模（2-4 个智能体）。
@Teamly 返回的团队会附带每个专家为何在此的合理理由，而不是套话模板。点击即可替换任何智能体。如果简报有偏差，可编辑修改。
关键在于结构化的简报强制清晰，然后组合出一个你在雇佣前可以审计的团队。
与预建团队相同的交接架构，适配你的特定问题。
Try it free first
You can test the whole thing free for 3 days on Teamly 5, no charge until day 4.
If you stay, pricing is $29/mo for 5 agents.
Cheap enough that one shipped feature pays for the month.
先免费试用
你可以在 Teamly 5 上免费测试整个方案 3 天，直到第 4 天才开始收费。
如果继续使用，5 个智能体的价格是每月 29 美元。
便宜到交付一个功能就够付一个月的费用。
The bottom line
The difference between a pile of agents and a pipeline is the handoff.
Four specialists writing to shared files, one orchestrator running them in order, each stage building on the last instead of starting from scratch.
Build the Planner and Coder first and run them as a two-stage chain. Once that flow feels solid, add the Tester and Reviewer.
By the time all four are wired up, you'll kick off a feature before bed and read a verdict with your coffee.
For daily notes on AI agents, vibe coding and Claude Code setups: https://t.me/zodchixquant 🧠
核心要点
一群散兵游勇的智能体与一条流水线之间的区别在于交接。
四个专门化智能体向共享文件写入，一个编排器按顺序运行它们，每个阶段在前一阶段的基础上构建，而不是从头开始。
先构建 Planner 和 Coder，作为两阶段链运行。一旦该流程感觉稳固，再添加 Tester 和 Reviewer。
等四个都串联起来后，你睡前启动一个功能，早上喝着咖啡就能读到裁决。
关于 AI 智能体、vibe coding 和 Claude Code 设置的每日笔记：https://t.me/zodchixquant 🧠