# Power features: skills, subagents, hooks, and settings
The difference between using Claude Code as a chat box in your terminal and running it as a configured engineering environment comes down to five features: custom slash commands and Skills, subagents for parallel work, hooks that fire your scripts on events, MCP servers wired into your project, and the settings.json that governs all of it. This lesson goes deep on each.
You already know Claude Code ships with built-in slash commands like /clear and /init. The power move is writing your own.
A custom slash command is just a Markdown file. Drop a file at .claude/commands/<name>.md in your repo and it becomes /<name> in that project. Put it in ~/.claude/commands/ and it works everywhere. The file body is the prompt; Claude runs it with your project context attached.
Here is a review.md that gives the team a consistent code review pass:
---
description: Review staged changes for bugs, security issues, and style
allowed-tools: Bash(git diff:*), Read
---
Review the staged diff below. Flag:
1. Logic bugs and edge cases
2. Security issues (injection, secrets, auth gaps)
3. Style deviations from CLAUDE.md
Be terse. Cite file:line. Skip praise.
Staged changes:
!`git diff --cached`Two things to notice. The ! prefix runs a shell command and injects its output into the prompt. The allowed-tools frontmatter scopes what this command may touch, so /review cannot wander off and edit files. You can also pass arguments with $ARGUMENTS or positional $1, $2.
Skills are the heavier, reusable cousin. A Skill is a folder containing a SKILL.md plus any scripts, templates, or reference docs Claude should load when the task calls for it. Where a slash command is one prompt you trigger manually, a Skill is a packaged capability Claude pulls in automatically when relevant: think "fill out our invoice template" or "generate a PDF from this data." The same Skills format works across Claude Code, the Claude apps, and the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, so a Skill you build once travels with you. See the official overview at docs.claude.com/en/docs/agents-and-tools/agent-skills.
Rule of thumb: reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for a slash command when *you* decide when to run it. Build a Skill when you want Claude to decide, and when the capability needs bundled files and scripts.
A subagent is a separate Claude instance with its own context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition →, its own system prompt, and its own restricted tool set, spawned by your main session to handle a focused job. The point is isolation: the subagent burns through a noisy task (reading 40 files, running a test suite) and returns only the conclusion, so your main context stays clean.
You define subagents the same way as commands, with Markdown files in .claude/agents/. Each one declares a name, a description that tells Claude *when* to delegate to it, and the tools it is allowed to use.
---
name: test-runner
description: Runs the test suite and diagnoses failures. Use after code changes.
tools: Bash, Read, Grep
---
You are a test specialist. Run the project's test command, read failing
output, locate the root cause, and report a concise fix. Do not edit
files unless explicitly asked.Now your main session can hand off: "use the test-runner to check this." Claude reads the description, matches the task, and delegates. Because the subagent has its own window, a thousand lines of stack traces never pollute your main conversation.
The real leverage is parallelism. You can ask Claude to fan out work across multiple subagents at once: one auditing dependencies, one writing docs, one refactoring a module. They run independently and report back. This is the same delegation pattern the Claude Agent SDK exposes programmatically, just driven from the terminal. Keep tool grants tight per subagent; a docs writer has no business with Bash.
Subagents and commands are things you invoke. Hooks are the opposite: shell commands that Claude Code runs *automatically* at defined points in its lifecycle, with no promptingpromptingPrompt engineering is the practice of designing and refining text inputs to guide large language models toward accurate, relevant, and reliable outputs.View full definition →. They are how you enforce rules instead of hoping Claude follows them.
The key lifecycle events:
PreToolUse: before a tool runs (you can block it)PostToolUse: after a tool succeedsUserPromptSubmit: when you hit enterStop: when Claude finishes respondingSessionStart: when a session opensThe classic use case: auto-format every file Claude edits. Add this to your settings.json:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "prettier --write \"$CLAUDE_FILE_PATHS\" 2>/dev/null"
}
]
}
]
}
}After Claude edits or writes any file, Prettier formats it. Claude never has to remember your style rules because the hook makes them non-negotiable. The matcher is a regex against tool names, and Claude Code passes context (like the edited file paths) through environment variables.
PreToolUse is even more powerful because it can block. A hook that exits with a non-zero status on PreToolUse cancels the tool call. Teams use this to forbid edits to secrets/, block git push --force, or require a passing lint before a commit. The hook is your guardrail, running deterministically outside the model's judgment.
One caution: hooks run real shell commands with your permissions. Read what you paste. A hook from an untrusted repo can do anything you can do. The full event reference and the JSON your hooks can emit live at docs.claude.com/en/docs/claude-code/hooks.
You met the Model Context Protocol as a concept: a standard way to expose tools and data to any AI client. Claude Code is an MCP client, which means you can plug the same servers you'd use in the Claude desktop app directly into your terminal sessions.
Add one with the CLI:
claude mcp add github -- npx -y @modelcontextprotocol/server-githubThat registers a GitHub MCP server. Once connected, Claude can open issues, read PRs, and inspect repos as native tools, no glue code. The servers you add can be scoped to a single project or made available globally, and project-scoped servers can be checked into the repo so your whole team gets the same integrations.
This is the bridge between Claude Code and the wider ecosystem. The connectors you see in the Claude apps and the connector marketplace are MCP under the hood, and the same protocol spec is documented at modelcontextprotocol.io. Build a server once and it works in Claude Code, the desktop app, and anything else that speaks MCP.
Knowledge check
1. Where must you place a custom slash command Markdown file so that it is available across all of your projects rather than just one repository?
2. In a custom slash command file, what does the `!` prefix before a backtick command (e.g. ``!`git diff --cached` ``) do?
3. What is the primary purpose of the `allowed-tools` frontmatter in a slash command like `/review`?
4. Select ALL correct answers describing how Skills differ from custom slash commands in Claude Code.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about the five power features introduced in this lesson.
Sélectionnez toutes les réponses correctes.
Everything above is configured through one file, and understanding its layering is what separates a tidy setup from a confusing one. Claude Code reads settings from several locations, most-specific wins:
~/.claude/settings.json: your personal defaults, all projects.claude/settings.json: project settings, checked into git, shared with the team.claude/settings.local.json: your personal project overrides, git-ignoredThis layering matters. Put team-wide guardrails (the format hook, the allowed MCP servers) in the shared .claude/settings.json so everyone inherits them. Put your personal preferences and any machine-specific paths in settings.local.json so you don't fight your teammates in version control.
The most important key is permissions, which controls what Claude can do without stopping to ask. You allow, ask, or deny tool patterns:
{
"permissions": {
"allow": [
"Bash(npm run test:*)",
"Read",
"Edit"
],
"deny": [
"Bash(rm -rf:*)",
"Read(./.env)",
"Read(./secrets/**)"
]
}
}This lets Claude run your test scripts and edit files freely, never reads your .env or secrets, and refuses dangerous deletes. Tune this once and you stop babysitting confirmation prompts for safe operations while keeping a hard wall around the dangerous ones.
Other keys worth knowing: env injects environment variables into every session, model pins which Claude model the project uses, and hooks (above) lives here too. Keep the shared file minimal and intentional, because anyone who clones the repo inherits it. The full schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → is at docs.claude.com/en/docs/claude-code/settings.
These features are not separate toys; they stack. A real setup looks like this:
A SessionStart hook loads project conventions. Your permissions block green-lights the test command and walls off secrets. A /review slash command runs your standardized code review on demand. A test-runner subagent gets delegated the noisy work of running and diagnosing the suite. A PostToolUse hook formats every file Claude touches. A GitHub MCP server lets Claude open the PR when you're done. All of it defined in files that live in the repo, so a new teammate clones it and gets the exact same configured Claude on day one.
That reproducibility is the whole game. You are not promptingpromptingPrompt engineering is the practice of designing and refining text inputs to guide large language models toward accurate, relevant, and reliable outputs.View full definition → an assistant; you are shipping a configured engineering environment alongside your code.
.claude/commands/; a Skill is a bundled folder that travels across Claude Code, the apps, and the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →.PostToolUse for auto-formatting, PreToolUse to block forbidden actions. Hooks run real shell commands with your permissions, so audit anything you didn't write.claude mcp add wires the same servers and connectors used across the Anthropic ecosystem into your terminal, project-scoped and shareable.settings.local.json