Roles and tiers
On this page
The team is a set of roles, each a Claude Code agent with its own job, checklist and report. Roles exist to keep checks independent, not for role play: the developer who wrote the code is never the one who verifies it.
The roles
The main session is the Dev Manager and the only one that hands out work. Every other role is an agent that reads its inputs from files and returns one report.
| Role | Runs as | Default tier | Used for |
|---|---|---|---|
| Dev Manager | the main session | Opus | Every ticket: sizing, staffing, stops and handoffs |
| PM | kotharo:product-spec-writer | Sonnet | Requirements for new features |
| UX | kotharo:ui-designer | Sonnet | Interface changes |
| Architect | kotharo:plan | Opus | Design questions on bigger tickets |
| Senior dev | kotharo:implementor | Sonnet, Opus on escalation | Large or complex work |
| Dev | kotharo:implementor | Sonnet | Medium work, and the floor for risky code |
| Junior dev | kotharo:implementor | Haiku | Small, isolated changes |
| QA | kotharo:verifier | Sonnet | Checks the work against the acceptance criteria |
| DevOps | kotharo:deployer | Sonnet | Deploys and proves the deploy is live |
A role agent never asks you anything directly. When it can't go on, it reports BLOCKED with its question, and the Dev Manager turns that into a stop.
Fewest roles, lowest tier
Every ticket starts on the direct path: the main session makes the change itself, with no other agents. It brings in the team when the work grows past that, such as more than 8 files, more than 2 projects, or a risk signal like a migration, auth, tenant data or a public contract. By default it asks you before it does.
When the team is staffed, the ticket's size picks the developer and the tiers:
- A small ticket goes to the junior dev, a medium one to the dev, and a large one to the senior dev.
- The architect joins only a medium or large ticket with a design question, such as a public contract, a migration or auth.
- A docs or config change needs no one before the build.
The team states who works on the ticket in one line, on the first stop before the build, or in its play back in chat when the lane has no such stop.
Tier floors
Work on tenant-scoped data, migrations, auth, public contracts or sensitive data never runs below Sonnet, whatever its size. A floor signal also adds its gate, such as the tenant safety auditor for tenant data, and that gate always gets the reviewer's risk tier.
Escalation
A developer's task moves up one tier, to Opus at most, on any of these:
- a second test failure on the same task, not counting a flaky test;
- a Major finding from a gate's reviewer;
- a QA rejection;
- a design question the developer raised.
A lower tier never decides its own escalation. Each one is recorded in the ticket's handoff.md.
Limits
- At most 3 agents run at once in a session.
- At most 8 agents work on one ticket. Going past the plan or the cap needs a reason in
handoff.md.
Modes
A mode presets how much process a ticket gets, without touching its gates, its stops or the autonomy level.
| Mode | Review fix rounds | Agents per ticket | Before the build |
|---|---|---|---|
| lean | 1 | 5 | No one |
| balanced | as set | as set | As the size calls for |
| thorough | 3 | 10 | As the size calls for |
The team proposes lean for a small ticket and balanced for the rest. Choose one yourself with /kotharo:team ABC-123 --mode thorough, or at the first stop with Change mode....
Change a tier
At the first stop, Change staffing... adds or drops a role or a gate for this ticket. Where the lane has no stop before the build, say "change staffing" in chat. To change a tier for good, set it with /kotharo:config:
/kotharo:config set roles.senior-dev.tier opus --repoNext: Lanes and stops. All docs