agent-hierarchy

# 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. 1. **Inventory the real tree** — `git ls-files | sed 's|/[^/]*$||' | sort -u`. Report w...