Subagent roster — full tables & rationale

Full detail for CLAUDE.md §1. The spine carries a compact index and the invocation rules; the full per-agent tables and the concurrency rationale live here.

Agents live under .claude/agents/ (project) or ~/.claude/agents/ (user, all projects). Invoke them by name, or let them auto-dispatch on their description. They're scoped — each loads only the context it needs, so they're faster and less drift-prone than one mega-agent. In an Android repo, the project-scoped Android-flavored agents override the generic ones of the same name.

Core four-hat chain (§4 execution loop):

Specialists & contributors (pulled in around the four-hat chain — design upstream, ops downstream, the rest as the change warrants):

Delivery layer (§4B — wraps the execution loop):

Concurrency classification. Mutating agents hold Edit/Write and must run serially against the same branch; read-only agents omit Edit/Write and are safe to invoke in parallel. (Read-only agents may still hold Bash for inspection, so the boundary is a documented convention backed by the tools: list, not a hard sandbox — the Concurrency column above is the authoritative index.) Claude Code orchestrates serially today; an orchestrator that parallelized the read-only subset could read each agent's tools: allowlist to derive the safe set — typically a 2–5× speedup on multi-step turns. The read-only/mutating class is signalled by the tools: allowlist, not a frontmatter flag — concurrency: is not a supported sub-agent field, so the harness silently ignores it; the Concurrency column here is documentation for humans.

Model tiers. Model selection is by role, via the model: frontmatter field. Reasoning, review, design, implementation, and delivery agents carry no model: line, so they inherit your selected main model — thinking and decisions stay on the powerful model you chose, and follow it if you change it. The cheap ones in the generic / Android / iOS packs are docs-reconciler and the explorer utility, both pinned to sonnet: drift detection and code search are find-and-report work that doesn't need frontier reasoning, so they run on a cheaper model and hand back only their report — the file dumps land in the cheap agent's context, not your main one. The agents-compute/ pack keeps explicit pins at a finer grain — deep specialists (CUDA, numerics, parallelism, memory, systems, performance) on opus, routine implementation (build, python, inference plumbing) on sonnet — because compute work is rule-heavy and a deterministic per-role pin is worth it there. Rule of thumb: omit model: for anything that reasons or writes; pin to a cheap model only pure find-and-report work.

Utility agents (not part of the 42-agent roster). Alongside the roster, agents/ ships one read-only utility:

explorer is pinned to sonnet and does the grep/read churn in its own context, handing back a distilled answer so the file dumps never enter the calling model's context — the concrete way to "run reads on a cheaper model" (individual tool calls can't be routed per-model; delegation to a cheap subagent is the mechanism). It's a tool the roster and the main model call, not a workflow role, so it's counted separately from the 42.

Per-stack override packs. The generic roster ships in agents/ (15 roster agents + the explorer utility = 16 files). Stack-specific packs — agents-android/ (7), agents-ios/ (7), agents-compute/ (13) — override the global agent of the same name: when dropped into a repo's .claude/agents/. See STRUCTURE.md → "Agent override model" for which names each pack overrides and which globals fall through.