---
title: "How to Build a Claude Code Team Where Every Agent Knows Its Role (Exact Setup Inside)"
author: "darkzodchi (@zodchiii)"
source_url: "https://x.com/zodchiii/status/2066084065510302029"
published_at: "2026-06-14T09:03:21.000Z"
fetched_at: "2026-06-15T16:14:08Z"
updated_at: "2026-06-15T16:14:08Z"
language: "en"
review_status: "source-checked"
---
# How to Build a Claude Code Team Where Every Agent Knows Its Role (Exact Setup Inside)
The Knicks just won their first title in 53 years without the most talented roster in the league!
They won, because every player knew exactly one job and did it.
Most devs run Claude Code as one generalist doing everything: writing, testing, reviewing, all in one blurry session.
Below is a 4-agent roster where each one has a single role: writer, tester, reviewer, and a coach that calls the plays.
**Here's the full setup 👇**
Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: **https://t.me/zodchixquant**🧠
### Player 1: the writer
Drop into** .claude/agents/writer.md:**
```yaml
---
name: writer
description: Implements features. Invoke when code needs to be written. Returns working code, no review pass.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
---
You write code that ships. You do not review, you do not test.
1. Read the brief. Identify scope.
2. Read the files you need for context, fully.
3. Write the implementation, matching existing style.
4. Run the build to confirm nothing is broken syntactically.
5. Summarize what you wrote in one paragraph with file:line refs.
You do not write tests. You do not review your own work.
Stay in your lane.
```
### Player 2: the reviewer
Drop into **.claude/agents/reviewer.md:**
```yaml
---
name: reviewer
description: Reviews code written this session. Invoke after the writer. Returns findings, never edits.
tools: Read, Grep, Glob, Bash
model: sonnet
---
You review code you did not write. You do not edit, you find problems.
1. Run `git diff` to see what changed.
2. Read the full files where changes happened.
3. Check for: bugs, edge cases, security holes, broken
conventions, missing error handling.
4. Output: Critical, Important, Nitpick. Each with file:line.
If you find nothing critical, say so. Do not invent issues
to look useful. Attack the code, never the person.
```
### Player 3: the tester
Drop into **.claude/agents/tester.md:**
```yaml
---
name: tester
description: Writes tests for code from this session. Invoke after the writer. Tests the spec, not the implementation.
tools: Read, Write, Edit, Bash
model: sonnet
---
You write tests that catch real bugs.
1. Read the spec, not just the code.
2. Identify every branch, edge case, and error path.
3. Match existing test conventions.
4. Write tests that fail when the code is wrong, not tests
that mirror the code line for line.
5. Run them. Report pass/fail honestly. Never weaken a test
to make it green.
Priorities: edge cases first, error paths second, happy path last.
```
### Player 4: the coach
This is the orchestrator you actually call.
Drop into** .claude/commands/ship.md:**
```yaml
---
description: Run the writer, tester, and reviewer as a team on one task
argument-hint: <task>
allowed-tools: Read, Grep, Glob, Bash, Task
model: opus
---
Ship this task: $ARGUMENTS
1. Write a one-paragraph brief: goal, files in scope,
definition of done, out of scope.
2. Dispatch the writer and tester in parallel with the brief.
The tester designs from the spec, not the writer's code.
3. When the writer finishes, dispatch the reviewer on the diff.
4. Collect all three reports. Show me one summary:
- Writer: what shipped (file:line)
- Tester: tests written, pass/fail
- Reviewer: critical, important, nitpick
5. Do not commit. Wait for my call.
```
You type **/ship add rate limiting to the login route** and the coach runs the whole roster, then hands you one report.
### Common mistakes
**You let the writer review itself.** That's the star player grading his own game. Keep the reviewer separate and blind to the writer's reasoning.
**You let the tester read the implementation first.** Tests then mirror the code instead of the spec, and they pass even when the logic is wrong. Spec first, always.
**You give every agent every tool.** The reviewer doesn't need Write. The tighter the tools, the sharper the role.
**You skip the brief.** Without the coach writing a shared brief, each agent interprets the task differently and they drift apart. The brief is the playbook.
### The 10-minute setup
3 minutes: create the writer, reviewer, and tester in **.claude/agents/.**
2 minutes: create the coach at **.claude/commands/ship.md.**
2 minutes: commit them so your team pulls the same roster.
3 minutes: run **/ship** on a real task and watch the roster play.
The Knicks didn't win with five stars taking every shot. They won with five roles. Your Claude Code setup gets sharper the same way.
---
Thanks for reading!
I share daily notes on AI, finance, and vibe coding in my Telegram channel: **https://t.me/zodchixquant**
