Subagents, hooks and plugins

Three more ways to shape your agent: subagents hand focused work to specialists with their own context; hooks run your own code at fixed moments, which is the only way to guarantee a rule; and plugins bundle all of it so a whole team gets the same setup in one install.

1. The idea

Custom commands (saved prompts you run with /name) have largely merged into skills (Module 11): in Claude Code a command and a skill are now the same thing.

2. How it works

A subagent keeps the main context small

Ask "how does our auth handle token refresh?" in a big codebase. Watch both context windows.

A hook can stop an action before it happens

3. Try it yourself: the hook simulator

An agent is about to run these commands. Turn on rules for your "before shell command" hook and see what gets through. Then look for the gaps: a hook is only as good as its patterns.

4. Why it matters at work

Good subagents

code-explorer (searches a large codebase and reports only the answer), security-reviewer (read-only, checks a diff for injection, authorisation and secrets), test-writer, docs-updater. Give each a precise description of when to use it, the fewest tools it needs, and a fixed output format. Use a cheaper model for search-heavy specialists and a stronger one for reviews (Module 04).

Good hooks

A blocking hook in Claude Code, for example: a PreToolUse hook that exits with code 2 stops the tool call, and whatever it printed to standard error is shown to the model as the reason.

#!/usr/bin/env bash
# .claude/hooks/block-dangerous.sh: receives the tool call as JSON on stdin
cmd=$(jq -r '.tool_input.command // ""')
if echo "$cmd" | grep -Eq 'rm -rf|git push .*--force|DROP TABLE|\.env'; then
  echo "Blocked by team policy: $cmd" >&2
  exit 2          # blocks the call; this message goes to the model
fi
exit 0

Plugins: the five-minute review

1. Who publishes it? A vendor or known maintainer beats an anonymous repository.
2. Read what it adds: its skills, subagents, hooks and MCP servers.
3. Hooks and MCP servers are code that runs. Look for network calls, reads outside the repo (~/.ssh, .env) and obfuscated content.
4. Pin a version for team use; every update is new code to review.
5. Install at the narrowest scope (project, not user-wide) until it's trusted.

5. In your five tools

All five tools now have all three. Checked October 2026.

Git's own pre-commit hooks also work with every tool, because they run whoever (or whatever) commits.

6. Remember it

7. Common mistakes

8. Hands-on lab (roadmap week 12)

1. A read-only security-reviewer subagent: clear description, read-only tools, a fixed findings format. Run it on a real diff.
2. A blocking hook for destructive commands. Try to get past it with variations (rm -fr, a different path) and tighten it.
3. A formatting hook that runs your formatter after every file edit.
4. A command or skill /review-pr that runs your review checklist on the current branch.
5. Cross-check the subagent and hook in a second tool (the table in section 5 shows where they live).

9. Self-check quiz

10. Go deeper