The Orchestration Roundup

The list first: four primitives and six ready-made things

How to install (commands copied from each official page)

# 6-8 official marketplace, added on your first interactive session; add it manually if not
/plugin marketplace add anthropics/claude-plugins-official
/plugin install security-guidance@claude-plugins-official
/plugin install hookify@claude-plugins-official
/plugin install feature-dev@claude-plugins-official

# 5 agent teams are off by default; turn them on in settings.json env
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

# 9 the largest community marketplace, same two steps
/plugin marketplace add wshobson/agents
/plugin install python-development          # or any of its 94 plugins

# 1 a subagent is just a markdown file with frontmatter; nothing to install
# .claude/agents/reviewer.md -- name and description are the only required fields

# Do these two right after installing anything
/plugin            # the Installed tab has a "Not used recently" group: who is billing you for nothing
/skill-doctor      # per-skill context cost

One by one, in plain words

• (1) subagent: a .claude/agents/*.md file where name and description are the only required fields; tools, disallowedTools, model, maxTurns, permissionMode and isolation: worktree are all optional. The whole value is the separate context window: throw log-trawling and repo-wide searches in there and take back only the conclusion. The hard numbers the docs state: 20 concurrent subagents by default (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS), 3 levels of nesting, and a startup warning once all agent descriptions together exceed 15,000 tokens. When not to use it: the answer was one sentence — a second context window is pure tax.
• (2) hook: a hooks block in settings that runs your shell command at a lifecycle point. The only deterministic mechanism in this class — it doesn't depend on the model remembering. The event table is wide now: PreToolUse, PostToolUse, PostToolUseFailure, PostToolBatch, UserPromptSubmit, PermissionRequest, PermissionDenied, SubagentStart, SubagentStop, Stop, TeammateIdle, TaskCreated, TaskCompleted, InstructionsLoaded, ConfigChange, FileChanged, PreCompact, SessionStart, SessionEnd and more. Two rules to memorize: a PreToolUse deny still holds under bypassPermissions and --dangerously-skip-permissions (hooks tighten, never loosen); and hooks on one event all run to completion in parallel before results merge, so one hook's deny does not suppress another's side effects. When not to use it: the task needs judgment — reach for type: "prompt" (single-turn) or type: "agent" (multi-turn, 60-second default timeout, up to 50 tool turns, marked experimental).
• (3) skill / slash command: two doors into the same thing now — .claude/skills/<name>/SKILL.md (multi-file, hot-reloaded), with the older .claude/commands/<name>.md still supported but single-file. Two frontmatter fields decide who can fire it: disable-model-invocation: true means only you can type it (right for a /deploy), user-invocable: false means only the model uses it. Three underrated powers: !`command` injects shell output before the model sees the content, allowed-tools pre-approves permissions for the turn, and context: fork runs the command in an isolated subagent. When not to write one: a task you'll do once.
• (4) plugin: a directory with .claude-plugin/plugin.json that packages skills, agents, hooks and MCP servers as one installable unit. Not a fifth capability — a shipping crate. The docs are blunt about the price: an enabled plugin is part of every session, not only the ones where you use it. For everything the model can invoke on its own, the name and description are in context on every turn. Check Context cost in /plugin before installing and Not used recently after. When not to package: one machine, one user — just drop it in ~/.claude/.
• (5) agent teams (experimental, off by default): a teammate is not a subagent but a complete, independent Claude Code session, sharing a task list and messaging the others through mailbox files; you can talk to any of them directly. The documented sweet spot is specific: five teammates each holding one hypothesis and trying to disprove the others, which breaks the anchoring that ruins single-threaded investigation. The limits are equally specific: no resumption (/resume does not restore in-process teammates) · no nesting · one team per session · the lead can't be transferred · shutdown is slow · task status lags. The docs suggest starting with 3–5 and say plainly that three focused teammates often beat five scattered ones.
• (6) security-guidance (official plugin): install this one first, and read it as the best worked example of hook orchestration there is — the entire plugin is built out of hooks, in three deepening layers. PostToolUse on Edit/Write does a pure string-pattern match (eval(, pickle, dangerouslySetInnerHTML, edits under .github/workflows/) with no model call and no cost. Stop runs a background diff review at the end of each turn (up to 30 changed files per turn, at most three in a row). PostToolUse on Bash, filtered to git commit and git push, runs a deeper agentic review that reads surrounding code (capped at 20 per rolling hour). The key design choice: the instance that wrote the code never grades itself — a separate Claude starts fresh and is told only to find problems. Honest caveat: none of the three layers blocks a write or a commit. They hand findings back for Claude to fix.
• (7) hookify (official plugin): it automates writing hooks. /hookify [description] takes one sentence, or reads the conversation for the behavior that has been annoying you, and generates a markdown rule with YAML frontmatter (event, pattern, action: warn|block). No restart — the rule applies on the next tool use. /hookify:list and /hookify:configure manage the switches. When not to install: you already hand-write hook config, in which case it is one more layer of indirection.
• (8) feature-dev (official plugin): one /feature-dev command opens a seven-phase workflow carrying three clearly split agents — code-explorer (traces execution paths to map what exists), code-architect (produces the architecture and implementation blueprint) and code-reviewer (hunts bugs and convention violations). The split is the part worth studying: exploration, design and review each get their own context, and none of them vouches for another. The same marketplace also carries code-review (multi-agent PR scoring) and claude-code-setup (scans your repo and tells you which automation to configure). When not to use it: a one-line change.
• (9) wshobson/agents (community marketplace, MIT): per its README, 2026-09, it describes itself as 94 plugins / 202 agents / 183 skills / 105 commands, and claims support for Claude Code, Codex, Cursor, OpenCode and GitHub Copilot among others. Installation is identical to the official marketplace. Use it to take one plugin you need, not to install the repo — go back and reread the context tax in item (4).
• (10) disler/claude-code-hooks-mastery (community repo): 13 hook lifecycle events written out one by one as runnable example scripts (UV single-file scripts, each hook isolated), plus a Builder/Validator validation pair and a meta-agent that generates subagents. The one entry here to read rather than install: adapting it beats starting from scratch. Note: community repos trail the official event table, so take event names from the official hooks docs.

Why these ten don't compare: there are only two axes

The three common mismatches are all visible on that grid:

• Writing a deterministic rule as an instruction. "Run lint before every commit" in CLAUDE.md takes work from the bottom-right cell and drops it in the middle one, where it becomes advice the model can forget. It should be a PostToolUse hook, or one sentence to (7).
• Writing a judgment call as a hard hook. "Don't touch this directory" can be blocked outright. "Is this change a security problem" cannot. Two legitimate routes for the latter: a single-turn type: "prompt" hook, or copy (6) — a Stop hook that spins up a separate Claude in the background and feeds the verdict back.
• Using a subagent as a teammate. The comparison table is explicit: a subagent returns its result to the caller, the main agent manages everything, and the token cost is lower; teammates message each other directly, claim their own tasks, and cost more (each is a full instance). Teams are for work that needs discussion and challenge. If you just want a conclusion, use a subagent.

One more thing that's easy to miss: turning (5) on changes ordinary delegation too. Per the docs, while agent teams are enabled, a subagent that Claude names on its own launches as a teammate — so a team can form when you never asked for one. Set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS back to 0 if you don't want that.

Three-minute check: answer these six before you install

1. Does this need model judgment? No → (2) a hook, or (7) to generate one. Yes → (3) a skill or (1) a subagent. Get this one wrong and everything after it is wrong.
2. Does the result need to come back in full? No (logs, repo-wide search, long diffs) → (1) a subagent. Yes → just do it in the main conversation.
3. Must it happen every single time? Then only (2) guarantees it. Anything in CLAUDE.md is advice, not a guarantee.
4. Should the model be able to fire it? Yes → the description must say when to use it. No → disable-model-invocation: true, so nothing runs your /deploy on a hunch.
5. How much context does it hold permanently? The official line: for everything the model can invoke, name and description are in context every turn. Check Context cost before, Not used recently and /skill-doctor after. (1) adds one of its own: a warning once all agent descriptions exceed 15,000 tokens.
6. How many people and machines? One person → ~/.claude/. One repo → commit .claude/. Across repos or teams → now (4) and a marketplace are worth it.

The honest cost: orchestration is the expensive tier

Three bills

• The standing context tax. The one you pay daily and never see itemized. Installing five plugins from (9) is easy; their names and descriptions are in every turn from then on. The only defense is checking Not used recently and turning things off.
• A hook runs arbitrary code as you. Whatever it runs, it runs with your privileges. Two practical traps: hooks on one event run in parallel and one deny doesn't suppress another's side effects; and PreToolUse Bash matching is best-effort — the docs say plainly to use the permission system, not a hook, for a hard allow or deny.
• Agent team tokens scale linearly. The docs say "significantly more" than a single session, and an in-process teammate's requests fall outside the main conversation's cache bucket, defaulting to a 5-minute TTL (subagentPromptCacheTtl raises it to 1h, but 1-hour cache writes bill higher). And on permissions: if the lead starts with --dangerously-skip-permissions, every teammate inherits it.

What you can do without installing anything

1. Write two hooks before you write an agent. Most of what people mean by "it keeps forgetting X" is one PostToolUse hook. If you don't want to write it, (7) will.
2. Install (6) first — zero config, and most of it is free. The per-edit pattern match makes no model call; only the end-of-turn and commit layers spend, and both are capped.
3. Try subagents before a team. The agent teams page itself opens with it: before you set up a team, check whether a lighter option does the job.