Most people use Claude Code like a slightly smarter terminal autocomplete. They type a request, Claude generates code, they copy it somewhere. That's fine, but it's leaving most of the tool on the table.
Claude Code has a full extensibility stack: slash commands, hooks, skills, subagents, MCP servers, and plugins. Each one solves a different problem. Understanding which to reach for, and when, is what separates reactive usage from actually building a system.
CLAUDE.md: The One File That Changes Everything
Before touching any of the advanced features, get your CLAUDE.md right.
This file is the agent's "constitution" — the primary source of truth for how your specific repository works. Every session, Claude reads it. Every session, it anchors Claude's behavior without you having to re-explain your project, your conventions, or what commands to run.
A minimal CLAUDE.md worth having:
# Project: my-tool
## Build
npm run build
## Lint
npm run lint -- --fix
## Test
npm test
## Conventions
- TypeScript strict mode
- No default exports
- Commit format: feat/fix/chore(scope): description
Claude adds hooks for what code should run before edits are accepted — like running Prettier on a specific file — or after edits, like running a type check to make sure only correct files are accepted. But all of that scaffolding works better when Claude already understands the project structure from CLAUDE.md before it starts touching anything.
For hobby projects, let Claude manage CLAUDE.md. For anything you care about, own it yourself.
Slash Commands: Deterministic Shortcuts
Slash commands provide a way to control Claude Code sessions with special commands that start with /. These commands can perform actions like clearing conversation history, compacting messages, or getting help.
The built-ins handle session hygiene: /clear, /compact, /context, /hooks. The interesting part is custom commands.
To add commands, create a .claude/commands folder, add the command name as a file with a .md extension. Write these in natural language and use the $ARGUMENTS string to place arguments into the prompt.
A working example:
mkdir -p .claude/commands
cat > .claude/commands/review-pr.md << 'EOF'
Fetch the PR diff for $ARGUMENTS using gh pr diff.
Review for: logic errors, security issues, missing error handling.
Do not comment on style or naming conventions.
Produce a structured list: Critical / Important / Minor.
EOF
Invoke it with /review-pr 142. Claude fetches the diff, runs the review, formats the output exactly as specified.
Slash commands are user-invoked, single-file entries with terminal /... discovery and autocomplete. Skills are structured, auto-discovered capabilities that Claude may apply when relevant. Know the distinction before you start building — it determines where the thing lives and how it gets triggered.
The .claude/commands/ directory is the legacy format. The recommended format is .claude/skills/<name>/SKILL.md, which supports the same slash-command invocation (/name) plus autonomous invocation by Claude. If you're starting fresh, go straight to the skills format.
Skills: Context That Claude Loads Automatically
Skills are the architectural shift. Unlike commands you invoke manually, skills are model-invoked — Claude autonomously uses them based on context. Location: .claude/skills/ for project scope, or ~/.claude/skills/ for personal scope across all projects.
Every skill is a directory with a SKILL.md file. The YAML frontmatter controls when Claude loads it:
---
name: generate-commit-messages
description: Generates clear commit messages from git diffs. Use when writing
commit messages or reviewing staged changes.
---
## Instructions
1. Run `git diff --staged` to see changes
2. Write a commit message: summary under 50 chars, detailed description below
3. Use present tense. Explain what changed, not what you did.
Skill descriptions are loaded into context so Claude knows what's available. If you have many skills, they may exceed the character budget. The budget scales dynamically at 2% of the context window, with a fallback of 16,000 characters. Run /context to check for a warning about excluded skills. To override the limit, set the SLASH_COMMAND_TOOL_CHAR_BUDGET environment variable.
Keep skill descriptions tight and specific. Vague descriptions trigger false positives — Claude loads a skill that doesn't match the task and wastes context. Name the exact scenario in the description.
A skill directory can also contain supporting scripts, reference files, or templates. The SKILL.md instructs Claude to use them. This is what makes skills genuinely powerful for complex workflows: the instruction file orchestrates external resources instead of trying to pack everything into a single prompt.
Hooks: Deterministic Rules Claude Cannot Override
CLAUDE.md is advisory. Hooks are mandatory.
Hooks are the deterministic "must-do" rules that complement the "should-do" suggestions in CLAUDE.md. A PreToolUse hook wrapping any Bash(git commit) command can check for a required file that a test script only creates if all tests pass. If the file is missing, the hook blocks the commit, forcing Claude into a test-and-fix loop until the build is green.
Hook configuration lives in .claude/settings.json:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npx prettier --write $FILE_PATH"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "echo \"$(date): $CONVERSATION_SUMMARY\" >> ~/.claude/activity.log"
}
]
}
]
}
}
You can also use the interactive /hooks command in Claude Code to configure hooks through a menu interface, which is often easier than editing JSON directly.
The practical hook strategy: block at submit time, not at write time. Avoid blocking-at-write hooks on Edit or Write operations — let the agent finish its plan, then check the final result. Blocking mid-edit breaks Claude's reasoning chain and produces worse outcomes than letting it complete a pass and then validating.
Use hooks for formatting, logging, pre-commit validation, and desktop notifications when long tasks complete. Do not use them to replace logic that belongs in CLAUDE.md.
Subagents: Context Isolation for Complex Tasks
The pitch is simple: a complex task requires X tokens of input context, accumulates Y tokens of working context, and produces a Z token answer. Subagents farm out the work to specialized agents, which only return the final answers, keeping your main context clean.
The tradeoff is real. If you build a PythonTests subagent, you've hidden all testing context from the main agent. It can no longer reason holistically about a change. Subagents are not free. Use them when context isolation genuinely matters — running parallel research branches, executing sandboxed tool calls, or maintaining a clean main session on a long-running task.
Subagent files live in .claude/agents/ with the same YAML frontmatter pattern as skills. The distinction is invocation: slash commands can invoke subagents for planning, then the main Claude instance handles execution. This gives you structured workflows with full tool access.
MCP Servers: External Tool Integrations
MCP (Model Context Protocol) connects Claude Code to external services — GitHub, databases, browser automation, internal APIs. The server handles the integration; Claude handles the reasoning about what to do with it.
# Add a stdio MCP server
claude mcp add github -- npx -y @modelcontextprotocol/server-github
# Add an SSE transport server
claude mcp add --transport sse my-service https://my-service.internal/mcp
Connecting external services like Asana, Gmail, and Salesforce expands what Claude Code can do beyond the local filesystem. The more interesting use case for security and embedded work: connecting Claude Code to custom internal tooling — CAN bus loggers, firmware flash interfaces, scan automation — and letting it reason about the output without manually piping data into the session.
Plugins: Bundled, Shareable Workflows
A plugin is a collection of related slash commands, agents, skills, and hooks bundled together. A marketplace is a collection of plugins from the same source — Anthropic has one where you can find their public plugins.
Build plugins when you've stabilized a workflow you want to share or replicate across projects without manually copying .claude/ directories. Before installing any community plugin: plugins can include code in both skills and hooks. Never install and let Claude run code you haven't reviewed first. That applies especially to hooks, which execute with your credentials.
The Session Discipline That Actually Matters
The tooling only works if the session stays clean.
Use /clear often. Every time you start something new, clear the chat. You do not need all that history eating your tokens, and you do not need Claude running compaction calls to summarize old conversations.
/compact is the middle option — it summarizes older context without discarding it entirely. Useful when you are mid-task and context is getting long, but you still need continuity. --dangerously-skip-permissions removes per-action confirmation prompts, which is reasonable for trusted environments where you've validated your hook and permission configuration.
The session discipline is: start clean, scope the task, use /clear between tasks. Everything else — hooks enforcing quality gates, skills auto-loading relevant context, commands encoding your process — works better when the session itself is not carrying dead weight from three problems ago.
If you want a field manual covering this full stack — CLAUDE.md patterns, hook configurations, skill architectures, and MCP server setups for security and embedded workflows — I put one together at numbpilled.gumroad.com/l/claudefield.
Top comments (0)