Power features: skills, subagents, hooks, and settings

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.Voir la définition complète →, 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.Voir la définition complète → 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.

Subagents for parallel work

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.Voir la définition complète →, 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.

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.

Hooks that run your scripts on events

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.Voir la définition complète →. 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 succeeds
• UserPromptSubmit: when you hit enter
• Stop: when Claude finishes responding
• SessionStart: when a session opens

The classic use case: auto-format every file Claude edits. Add this to your settings.json:

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.

MCP servers inside Claude Code

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:

That 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.

settings.json: the control plane

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-ignored

This 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.Voir la définition complète → is at docs.claude.com/en/docs/claude-code/settings.

How the pieces compose

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.Voir la définition complète → an assistant; you are shipping a configured engineering environment alongside your code.

Key Takeaways

• Write slash commands for tasks you trigger; build Skills for capabilities Claude invokes itself. A command is one Markdown prompt in .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.Voir la définition complète →.
• Use subagents to protect your main context. Delegate noisy, focused jobs to isolated agents with tight tool grants, and fan them out in parallel for independent work.
• Make rules deterministic with hooks. PostToolUse for auto-formatting, PreToolUse to block forbidden actions. Hooks run real shell commands with your permissions, so audit anything you didn't write.
• Treat MCP as your integration layer. claude mcp add wires the same servers and connectors used across the Anthropic ecosystem into your terminal, project-scoped and shareable.
• Commit your `settings.json` and design the layering.