Claude Code: The 5 Features Most Developers Ignore

Most Claude Code users stay in the chat interface — asking it to write functions, fix bugs, explain code. But Claude Code is also a platform with a layered configuration system, and most developers never go past the first layer.

Five features make up that system: CLAUDE.md, Skills, Sub-Agents, Hooks, and MCP Servers. Each solves a different problem.

1. CLAUDE.md — The Instructions That Never Leave

CLAUDE.md is a plain markdown file that loads into every Claude Code session automatically. Put it in your project root and Claude reads it before doing anything else.

The file system is hierarchical. Four levels, each overriding the previous:

Scope	Path	Shared with
Enterprise	macOS: /Library/Application Support/ClaudeCode/CLAUDE.md Linux: /etc/claude-code/CLAUDE.md	All users org-wide
Project	./CLAUDE.md or ./.claude/CLAUDE.md	Team via git
Personal	~/.claude/CLAUDE.md	Just you, all projects
Local	./CLAUDE.local.md	Just you, auto-gitignored

The most useful pairing: project CLAUDE.md for team standards (committed to git), and CLAUDE.local.md for personal sandbox URLs or preferences you don’t want to share.

Claude walks up the directory tree from your working directory, loading each CLAUDE.md it finds. Subdirectory CLAUDE.md files load on-demand when Claude reads files in those directories — so you can put a src/api/CLAUDE.md with API-specific rules that only activate when Claude is working in that part of the codebase.

What belongs in CLAUDE.md:

• Build and test commands
• Architecture decisions
• Non-negotiable coding standards
• Team workflow (branching, PR conventions)
• File organization rules

One number to remember: 200 lines. Keep each file under that. Longer files consume more tokens AND Claude’s adherence drops — it’s harder to follow a wall of text than a focused set of rules. For large teams, use a .claude/rules/ subdirectory with separate files and optional path scoping.

You can also import other files with @path/to/file syntax, which expands at session launch (max 5 hops deep).

2. Skills — Context That Loads When You Need It

If CLAUDE.md is always-on, Skills are on-demand. You create a SKILL.md file with instructions, and Claude adds it to its toolkit. The description is always available in Claude’s context. The full content only loads when the skill is actually invoked.

A team might have 20+ skills defined. Loading all 20 fully into every session would consume significant context. Instead, skills keep a small footprint — Claude knows what’s available (descriptions), and loads the full instructions only when relevant.

Skills live in:

• ~/.claude/skills/<name>/SKILL.md — personal, all your projects
• .claude/skills/<name>/SKILL.md — project-level, committable

Each skill is a directory with SKILL.md as the entrypoint. You can add supporting files: templates, examples, scripts — anything the skill might reference.

Invocation control is where skills get interesting:

Frontmatter	You can /invoke	Claude auto-triggers	Description in context
(default)	Yes	Yes	Yes
disable-model-invocation: true	Yes	No	No
user-invocable: false	No	Yes	Yes

Skills also support arguments via $ARGUMENTS substitution and dynamic context injection. The !command syntax (backtick-wrapped shell commands) runs before Claude sees the skill content. A `/pr-summary` skill can run `!`gh pr diff to inject live PR data before the analysis prompt.

The budget for skill descriptions: 2% of the context window (fallback: 16,000 characters). Run /context to see if any skills are being excluded due to that limit.

3. Sub-Agents — Isolated Workers for Isolated Tasks

Sub-agents are specialized AI assistants that run in their own context window. When Claude delegates a task to a sub-agent, the agent works independently and returns a summary — its full output, including any verbose intermediate results, stays in its own context and never enters your main conversation.

This is the highest-ROI use case: running tests, fetching documentation, processing log files. Operations that produce large outputs. Keep the noise out of your main context.

Claude Code ships with six built-in sub-agents:

Agent	Model	Tools
Explore	Haiku (fast)	Read-only
Plan	Inherits	Read-only
General-purpose	Inherits	All tools
Bash	Inherits	Bash only
statusline-setup	Sonnet	—
Claude Code Guide	Haiku	—

Explore is the one you’ll use most — it keeps exploration results out of your main context while letting Claude search and analyze your codebase. It supports three thoroughness levels: quick, medium, or very thorough.

Custom sub-agents live in .claude/agents/<name>.md (project) or ~/.claude/agents/<name>.md (personal). The frontmatter gives you full control:

---
name: code-reviewer
description: "Reviews code for quality and security. Use proactively after code changes."
tools: Read, Grep, Glob, Bash
model: sonnet
permissionMode: default
maxTurns: 30
---

You are a code reviewer. Analyze code and provide specific, actionable feedback.

Key fields:

• model: sonnet, opus, haiku, or inherit. Route cheap tasks to Haiku.
• tools: Allowlist. Restrict what the agent can touch.
• disallowedTools: Denylist. Deny specific tools from the inherited set.
• permissionMode: bypassPermissions for fully autonomous agents (use with care).
• memory: user, project, or local for persistent cross-session learning.
• background: true to always run concurrently.

At Cybernauten, our editorial workflow follows a staged process: Research → Writing → Editing → QA → Publishing. Each stage receives only the output of the previous stage — the writer never sees the raw research session, only the finalized research document.

One constraint to know: sub-agents cannot spawn other sub-agents. No nesting. If you need chained delegation, do it from the main conversation.

4. Hooks — Automation Claude Cannot Override

This is the feature with the widest gap between “how many people know it exists” and “how useful it actually is.”

Hooks are user-defined shell commands, HTTP requests, or LLM prompts that run automatically at 17 specific points in Claude Code’s lifecycle. The critical difference from CLAUDE.md instructions:

CLAUDE.md says “please don’t do X.” Claude tries to follow that.

A hook runs a shell script that exits with code 2 if X is attempted. Claude Code blocks the operation. Claude has no say.

The 17 event types:

Category	Events
Session	SessionStart, SessionEnd, PreCompact
Prompts	UserPromptSubmit
Tools	PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest
Agents	SubagentStart, SubagentStop
Tasks	Stop, TeammateIdle, TaskCompleted
Config	ConfigChange
Worktrees	WorktreeCreate, WorktreeRemove
Notifications	Notification

Configuration lives in settings.json (project or user scope), or inline in skill/agent frontmatter for component-scoped hooks.

The canonical example: blocking dangerous commands.

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/block-rm.sh"
          }
        ]
      }
    ]
  }
}

.claude/hooks/block-rm.sh:

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command' < /dev/stdin)

if echo "$COMMAND" | grep -q 'rm -rf'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive command blocked by hook"
    }
  }'
else
  exit 0
fi

When Claude tries to run a rm -rf command: PreToolUse fires, the matcher targets Bash, the script reads the tool input via stdin, detects the pattern, and outputs the deny decision. The operation is blocked before it runs.

Exit code semantics: 0 = allow, 2 = blocking error (stderr goes to Claude as an error message), anything else = non-blocking error.

Four hook handler types: command (shell), http (POST request), prompt (Haiku LLM call), and agent (spawns a sub-agent for multi-turn verification).

Other practical uses:

• PostToolUse on Edit|Write to run a linter automatically after every file change
• SessionStart to load environment variables or check required tools are installed
• PreCompact for session archiving — back up the transcript before compaction compresses it (what we use at Cybernauten)
• SubagentStart/Stop to set up and tear down database connections for specific agents

Hooks also compose with MCP tools. The matcher supports regex, so mcp__memory__.* targets all operations on the memory server.

5. MCP Servers — The External World

Model Context Protocol is an open standard that lets Claude connect to external tools, databases, and services. Add an MCP server and Claude gets new tools it can call — just like built-in tools, but sourced externally.

Three transport types:

Transport	Use when	Status
stdio	Local process (scripts, local databases)	Current
HTTP (Streamable HTTP)	Remote/cloud services	Current, preferred
SSE	Remote services	Deprecated — migrate to HTTP

Installation:

# Remote HTTP server
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Local stdio server
claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \
  --dsn "postgresql://user:pass@host:5432/db"

Three scopes control who sees a server:

Scope	Stored in	Visibility
local (default)	~/.claude.json	You, current project only
project	.mcp.json	Your whole team (commit to git)
user	~/.claude.json	You, across all projects

The project scope is the one teams should know about. Add --scope project and Claude Code creates a .mcp.json at your project root — commit it and every team member gets the same MCP tools automatically.

MCP tools follow a naming pattern: mcp__<server>__<tool>. The GitHub server gives you mcp__github__search_repositories, mcp__github__create_issue, and so on. This matters because hooks can target MCP tools directly — matcher: "mcp__memory__.*" would intercept all memory server operations.

Official registry: 100+ commercial servers covering version control (GitHub, GitLab), databases (PostgreSQL, Supabase), project management (Jira, Linear, Notion), monitoring (Sentry, Datadog), communication (Slack, Gmail), and browser automation (Playwright).

For OAuth-protected services, add the server then run /mcp in Claude Code to authenticate through your browser. Tokens are stored in your system keychain and refreshed automatically.

Context management note: With many MCP servers, tool definitions can consume significant context. Claude Code auto-enables Tool Search when MCP definitions exceed 10% of your context window — tools are deferred and loaded only when Claude actually needs them. Control via the ENABLE_TOOL_SEARCH env var.

How the Features Work Together

What you need	Feature
Rules that apply every session	CLAUDE.md
Project standards for your team	Project CLAUDE.md (committed to git)
Task-specific instructions on demand	Skills
Workflows only you should trigger	Skills with disable-model-invocation: true
Context isolation for verbose tasks	Sub-Agents
Cheaper model for simple tasks	Sub-Agents with model: haiku
Hard blocks on dangerous operations	Hooks — PreToolUse
Post-edit automation (linting, formatting)	Hooks — PostToolUse
Session lifecycle management	Hooks — SessionStart / PreCompact / SessionEnd
External tools, databases, APIs	MCP Servers
Team-shared external integrations	MCP with --scope project

These features compose: CLAUDE.md handles the persistent baseline, Skills handle task-specific knowledge on demand, Sub-agents isolate expensive or noisy work, Hooks enforce what shouldn’t be left to Claude’s discretion, and MCP connects Claude to the external world.

Each feature has a context cost profile:

Feature	Always in context	Footprint
CLAUDE.md	Yes	Full file (target under 200 lines)
Skills (descriptions)	Yes	2% of context window budget
Skills (full content)	On invoke only	Loaded on demand
Sub-agent results	No	Summary only
Hooks	No	Zero — external shell commands
MCP definitions	Yes (unless Tool Search)	Scales with server count

A practical starting point: add a project CLAUDE.md with your three most important team rules, create one disable-model-invocation skill for your deploy workflow, and drop the block-rm hook in .claude/settings.json. Those three steps alone change how the tool behaves in a team environment.

For a deeper look at Claude Code’s core functionality, see the Claude Code profile.

---

Verified against Claude Code documentation, March 2026. Sources: code.claude.com/docs.