Customizing Your Coding Agent: Commands, Hooks, and Subagents
Turn a general coding agent into your team's agent with custom commands, hooks that enforce rules, project subagents, and shared settings.
Out of the box, a coding agent is a brilliant generalist that knows nothing about how your team works. It doesn't know that every change gets formatted with your formatter, that "ready for review" means a specific checklist, or that payment code needs a security pass. You can type those things into every session, or you can teach the agent once and commit the result to the repo, so every teammate's agent behaves the same way from day one.
This lesson shows you how to turn a general coding agent into your team's agent. You'll learn the layers of customization and when to use each, how to write team commands that pull in live context, hooks that enforce rules instead of requesting them, project subagents with restricted tools, and shared settings. The examples use Claude Code, with the real equivalents in Codex and Cursor at the end.
The layers of customization
Each kind of customization solves a different problem. Picking the wrong layer is the most common mistake, like writing "always run the formatter" in an instructions file and then wondering why it's skipped one time in ten.
| Layer | What it is | Use it for |
|---|---|---|
| Instructions file | Markdown loaded into every session | Facts and conventions that are always relevant (lesson) |
| Skills and commands | Instructions loaded on demand or run by name | Repeatable workflows: release notes, PR prep, fixing an issue |
| Hooks | Scripts that run automatically at fixed points | Rules that must hold every single time |
| Subagents | Specialist agents with their own context and tools | Focused jobs like reviewing or researching, without cluttering the main session |
| Settings | Permissions, environment, hooks, plugins | Making the team's baseline identical on every machine |
| Plugins | Bundles of all of the above | Sharing one setup across many repositories |
The single most useful rule: if it must happen every time, it's a hook, not an instruction. Instructions are requests the model weighs against everything else in context. Hooks are code that runs whether the model remembers or not.
In Claude Code, almost all of this lives in a .claude/ folder at the root of your repo, committed to git:
.claude/
├── settings.json # shared permissions, hooks, env, plugins
├── settings.local.json # personal overrides, not committed
├── skills/
│ └── pr-ready/SKILL.md # a team command
├── agents/
│ └── security-reviewer.md
└── hooks/
├── format.sh
├── guard-tests.sh
└── require-green.sh