Audit and assign model tiers to every agent in the repo — classify each as planner, builder, or judge, and pin an explicit model per role so expensive models plan and judge while cheaper models execute. Use for "which agents should run on which model", "cut my token spend", "set up model tiers", "Opus is doing grunt work", or as part of /opus-pocus. Reports the classification table and the frontmatter edits; prescribes a lint so future agents must declare a tier. NOT for choosing the user's i...
Scanned 9/6/2026
Install to Claude Code
npx -y skills add Totes-MickGOATs/opus-pocus --skill sorting-hat --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Sorting Hat?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/totes-mickgoats-sorting-hat)More formats (shields.io, HTML) on the badges page.
---
name: sorting-hat
description: Audit and assign model tiers to every agent in the repo — classify each as planner, builder, or judge, and pin an explicit model per role so expensive models plan and judge while cheaper models execute. Use for "which agents should run on which model", "cut my token spend", "set up model tiers", "Opus is doing grunt work", or as part of /opus-pocus. Reports the classification table and the frontmatter edits; prescribes a lint so future agents must declare a tier. NOT for choosing the user's interactive session model — agents only.
---
# ✨ The Sorting Hat
> *"Not every task deserves the expensive wizard. Opus plans, Sonnet toils, Haiku fetches — Opus returns to judge."*
The thesis: use the top model as a **planner and judge, not an executor**. Architecture,
decomposition, and final review reward the strongest model; mechanical execution mostly doesn't.
An agent roster with no declared tiers runs everything on the session default — usually the
most expensive model doing the least discriminating work.
## What to scan
Every agent definition (`.claude/agents/*.md` and plugin agents), each one's `model:`
frontmatter (or its absence), its tool set, and what its body actually asks it to do.
## Classification
Read the agent's *task shape*, not its name:
| Role | Task shape | Tier |
|---|---|---|
| **Judge** | Reviews, audits, refutes, grades; output is a verdict someone acts on; being wrong is expensive | Top model (Opus-class) |
| **Planner** | Decomposes, architects, writes briefs others execute | Top model |
| **Builder** | Writes code/content against a settled spec; correctness is checkable downstream (compiles, tests, lints) | Mid model (Sonnet-class) |
| **Mechanical** | Renames, format fixes, lookups, file moves; a wrong answer is obvious and cheap | Small model (Haiku-class) |
Edge rules:
- An agent that both builds and self-reviews is a **builder** — the judging belongs in a
separate judge pass, which is the whole point of the split.
- Read-only auditors whose findings block a merge are **judges** even when cheap to run wrong —
a plausible-but-wrong finding costs more than the model saved.
- When genuinely torn, tier UP for verdict-producers, DOWN for artifact-producers.
## When this spell has no subject
**Fewer than about five agents: report the classification table and stop.** Do not prescribe a
decision record, do not prescribe a lint. Both are drift-control for a roster large enough to
drift; on three agents the frontmatter *is* the policy, and a human reading three files *is* the
enforcement. Prescribing governance for two lines of YAML is the scale inversion this book grades
elsewhere.
**A missing `model:` is not automatically a finding.** Inheriting the session model is the right
call when the agent's cost is negligible, or when the user's plan may not grant the tier you would
pin — a hard pin to a model the account cannot reach fails at dispatch, which is worse than an
untiered agent. Flag a missing `model:` only when the agent is **frequently dispatched** *and* its
role tier **differs from the session default**, and say which of the two you observed.
## Anti-patterns to find
1. **No `model:` on a frequently-dispatched agent whose tier differs from the session default** —
it silently inherits whatever the session runs, which is the wrong tier by the roster's own
classification. (On a small roster, or where the inherited tier is already correct, this is not
a finding — see above.)
2. **Judge on a builder tier** (a reviewer pinned to a small model to save cost).
3. **Mechanical work on the top tier** (a rename bot inheriting Opus).
4. **Tier decided at dispatch time per call** — callers guess differently; the definition is
the single source.
5. **No enforcement** — nothing makes the NEXT agent declare a tier, so the roster drifts back.
## Fix prescriptions
- Emit the full classification table: agent · current model · role · prescribed model · one-line
rationale. The user approves before edits.
- Apply as `model:` frontmatter edits — one per agent definition. Use the **alias**
(`opus` / `sonnet` / `haiku` / `inherit`), never a dated model ID: IDs age out and a stale one
fails at dispatch. Where the account may not hold the top tier, prefer `inherit` for judges and
pin only the down-tiers.
- **On a roster of about five or more:** record the policy as a decision doc (ADR or equivalent)
so the tiers are argued once, not re-litigated per agent.
- **On a roster of about five or more:** add the lint — a wiring or CI check that every agent
definition declares `model:`. The check, not the doc, is what keeps the roster sorted. Below
that size the lint governs less than it costs.
- Derived, never typed: if the repo documents the roster (a README table), generate the tier
column from the frontmatter — a hand-typed copy drifts.
## Bounds
- Scope: agent definitions and their frontmatter. Nothing else, and never the user's interactive session model.
- Cap: the full classification table is the deliverable, so no cap applies — but findings (mis-tiered agents) rank at 15.
- Done when every agent has been classified once. A repo with no agents gets `SCANNED NOTHING` and grades `N/A`, never `O`.
- Quote once, at read time; mark anything you cannot re-confirm `UNVERIFIED` rather than re-reading to check yourself.
- See `skills/opus-pocus/references/casting-safety.md` for the full rules.
## Report format
The classification table, the count of agents changed per direction (up-tiered / down-tiered /
newly declared), the estimated spend impact (which frequent agents moved down), and the lint
status (exists / prescribed). `SCANNED NOTHING` if the repo has no agents.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!