Agent Hierarchy
Designs orchestrator-and-subagent hierarchies for a repository, splitting agents by...
Install
npx skills add cbrock84/headcount --skill agent-hierarchy -g -a claude-code -y- Repository
- cbrock84/headcount2.6k
- Category
- Design
- Updated
- 17d ago
- License
- MIT
- Context cost
- Lightabout 1,078 tokens
- Runs scripts
- Yes, review before use
What it does
Designs orchestrator-and-subagent hierarchies for a repository, splitting agents by exclusive write surface, pairing every producer with an independent auditor, and enforcing the split with a script that runs in CI. Use this whenever the user wants to set up, expand, audit, or fix a multi-agent or subagent structure for a codebase; asks how to divide work between agents; wants agent charters, roles, or a surface map written; or is hitting agents that collide on the same files, review their own work, or drift from their remit. Also use when sizing a roster or deciding whether a new agent is justified.
Agent hierarchy
A method for standing up an orchestrator → specialist-subagent hierarchy, extracted from a working implementation of ~24 agents over a 1,500-file monorepo, machine-checked on every PR.
The whole method in one paragraph
Split agents by write surface, not by topic. Two classes only: builders, which edit
inside exactly one exclusive surface and never commit, and reviewers, which are permanently
read-only and can always run in parallel. The orchestrator, the main chat, is the sole
committer. Write the surface map before any charters, keep it in one Markdown file, and
enforce it with a script that runs in CI. Each row also carries an authority, autonomous,
proposes, or escalates, which answers the separate question of whether that agent's work may
land without a decision; most rows are autonomous, and gating everything makes the gate
meaningless. Producer and auditor are never the same agent. For
each class of fact, exactly one file owns it and everyone else derives.
Why topic splits fail
"One agent on SEO, one on UI" is the intuitive split and it breaks immediately: both end up
editing tokens.css. Neither is wrong, and neither can be held responsible. A surface split
has no such overlap by construction, which is exactly what makes it checkable.
Order of operations
Do not start writing charters early; the order is the method.
