7 subagents, day one: qa-reviewer fails a draft, 2 roles idle

This is a first-day field report rather than a proven playbook. The seven subagents were split along three design criteria: whether the output destination differs, whether the required expertise and judgment criteria differ, and whether the role is worth reusing independently. The author is explicit that only the first of these is mechanically checkable — you can look at the directories — while whether two jobs really use different evaluation standards often only becomes clear after running both in one agent. The qa-reviewer separation is the case where that second criterion was confirmed the hard way: a defect appeared, and only then was it clear the evaluation axes had genuinely differed.

Within the same repository, the opposite happened at the same time. builder and content-writer were defined as separate roles with different output folders (samples/ and articles/) and different expertise, yet for two articles whose sample code and prose were one-to-one coupled, running them as one agent was faster because no other judgment intervened between the steps. Meanwhile growth-marketer and revenue-analyst have never been invoked; the ops/kpi.md update that revenue-analyst was meant to own amounted to the main session adding a single line after one article was published.

What ties these together is that agent definitions live as Markdown files under .claude/agents/, so merging or splitting costs one or two file edits. That low correction cost is arguably the reason the author can leave the question open — and the reason a follow-up review after roughly a month of operation is planned to test whether 7 was the right number.