Nine Claude Code advanced features sit behind configuration files most developers never open. Subagents, skills, hooks, MCP servers, git worktrees, headless mode, checkpoints, session resume, and conversation branching each solve a different failure mode, from context bloat to two agents overwriting the same file.
Claude Code advanced features at a glance
Claude Code advanced features cover context isolation, repeatable procedures, event automation, and parallel git safety. Nine are worth knowing in 2026: custom subagents, locked skills, hooks, MCP servers, git worktrees, headless mode, checkpoints, session resume, and named sessions. Most are configured once per project rather than typed at the prompt.
The table below maps each feature to the problem it solves and the mechanism it uses. Read it as a routing table rather than a ranking; several features overlap on purpose, and you rarely need all nine in one repository.
| Feature | Solves | Mechanism |
|---|---|---|
| Subagents | Main-thread context bloat | Markdown agent specs in .claude/agents/ |
| Skills | Repeating the same instructions | Skill files in .claude/skills/ |
| Hooks | Formatting and safety checks | Shell commands bound to agent events |
| MCP servers | Reaching external tools and data | Model Context Protocol connections |
| Git worktrees | Parallel agents editing the same repo | Isolated working copies |
| Headless mode | Using the agent inside scripts | Non-interactive CLI invocation |
| Checkpoints | Recovering from a bad edit | /rewind to a prior state |
| Session resume | Losing earlier project context | --continue, --resume |
| Named sessions | Finding the right conversation later | -n plus a session name |
Custom subagents keep the main thread lean
Custom subagents are markdown files that define a separate agent with its own name, description, permitted tools, and optional model, which Claude Code invokes when a task matches. Because each subagent runs in its own thread, the main conversation receives only the result, not the entire exploration.
A subagent file lives in .claude/agents/ inside the project. The frontmatter you write carries the same fields the built-in agents use: a name, a description that tells the main agent when to delegate, a tools list, and an optional model that lets you route cheap work to a smaller model. The body of the file holds the instructions that subagent follows.
Two subagents cover a lot of ground. A reviewer reads a diff or pull request and reports problems before merge. A debugger reproduces a failure and proposes a root cause. Creating both takes one prompt to Claude Code, since the agent can write its own spec files.
Run /context inside the project to confirm both appear in the agent list before you rely on them. From there, a prompt like "review this PR before I merge it and tell me if there are any issues" triggers the reviewer automatically, and the transcript shows the reviewer running in its own thread until it hands back a single response.
The point is context economics. When a review agent reads twenty files, that reading happens inside the subagent's window. Only the review text comes back, so the main conversation stays usable for longer. Models do tend to produce weaker answers as a thread approaches its context limit, and this pattern delays that point rather than eliminating it.
Create subagents when you want to push work out of the main thread, or when a task needs fixed rules about tools (read-only, for example) or a specific model. For ordinary prompts, Claude Code already spawns its own subagents without configuration.
Skills become real workflows once you lock them
A skill is a markdown file holding a reusable procedure that Claude Code can either discover on its own or be forced to run. The advanced move is disable-model-invocation, which blocks automatic loading and restricts the skill to manual invocation only.
Skills sit in .claude/skills/ at project level, or in a user-level directory when you want them available everywhere. In the project case the skill is scoped to that folder, so /skills in a different repository will not list it. Exported skills from public repositories can be imported the same way, which is how most teams start.
The model only sees the skill's name and description when deciding whether to invoke it. Everything inside the file, the steps themselves, loads only after that decision. That makes the description the field worth writing carefully.
The split matters for anything with side effects. A deploy skill or a rollback skill should never fire because a model inferred intent from a sentence. Setting the disable flag keeps that skill out of the model's automatic discovery path until you type the command yourself.
In /skills a locked skill is marked as such, next to the ones the model may call on its own. A rollback skill locked this way runs only when you type /rollback yourself.
Skills also accept arguments. Typing the skill name followed by a value, such as the environment name, passes that value into the procedure and lets one skill handle multiple targets. /deploy staging runs the same deploy skill against a staging environment, which is the difference between four nearly identical skills and two flexible ones.
Hooks run your commands on agent events
Hooks bind shell commands to specific events in the Claude Code agent loop, so formatting, validation, or approval checks run automatically instead of depending on the model to remember them. They are configured in a settings file rather than described in a prompt.
The event list covers the full cycle: session start, setup, user prompt submission, pre-tool use, post-tool use, and more. A PostToolUse hook on edit and write operations can run a formatter after every file change. A PreToolUse hook can inspect a command and refuse it before it executes.
A working configuration pairs a matcher with a command. The matcher names the tools to watch, and the command names the script to run. Blocking works through the exit code: a non-zero exit from a pre-tool hook stops that tool call, which is how a safety script prevents a destructive command from running.
A concrete pair shows the shape of it. A PostToolUse hook matched against edit and write runs python claude_hooks/format_hook.py, which formats the file with prettier after every change. A PreToolUse hook runs a block-dangerous script whose exit code 2 cancels the tool call outright. In a live session, asking Claude Code to add a function to a messy file ended with the file already reformatted, with no instruction to format anything.
This is the feature with the steepest setup cost. Hooks are defined in project or user settings under a hooks directory, and a mistake there can silently stop a workflow rather than throw an error. Test each hook on a throwaway repository before trusting it in a project that matters.
MCP servers plug external data into the session
MCP servers connect Claude Code to external tools and data through the Model Context Protocol, an open standard for exposing capabilities to AI clients. This article references Granola, an AI note-taking app, as one example; the sponsorship of the source video does not change how the protocol works.
Granola records meeting audio on the machine instead of sending a bot into the call, keeps notes and calendar entries, and exposes those transcripts through its own server, which it released earlier in 2026. Once connected, a prompt can ask what was covered in a specific recent meeting and get an answer built from the real transcript. Asking the tool what came up in a recent Indonesian lesson returns the vocabulary from that lesson, pulled from the stored transcript rather than from memory.
The important pattern here is not Granola specifically. Any server that exposes a queryable store, whether a ticketing system, a data warehouse, or a documentation index, extends what the agent can reach without pasting content into the prompt manually.
Server count is a real cost. Each connected server adds tool definitions to the available set, and more tools mean more for the model to choose between. Connect what you use weekly and disconnect the rest.
Git worktrees let parallel agents share one repo
A git worktree is a second working directory attached to the same repository, which gives each Claude Code session its own isolated copy of the files while sharing one git history. It is the mechanism that makes parallel agents safe when they touch the same project.
Git itself has supported worktrees for years; Claude Code exposes them through a worktree flag that takes a name. Calling the tool twice with different names and different prompts produces two agents editing two separate working copies, so an unfinished bug fix cannot collide with an in-progress feature. In a two-terminal demo, one worktree named for the bug fix reproduced and patched a defect while a second named for a dark mode feature added UI code, and neither session saw the other's edits.
A third session outside any worktree can then act as the integrator. Asked to locate the changes across the worktrees and combine them, it reads each isolated copy, reports what each contains, and merges the results. The isolation is what makes that merge reviewable instead of a conflict pile.
The limitation is disk and attention. Each worktree is a full checkout, and every additional parallel agent is another thing to reconcile. Two or three concurrent worktrees suit most work; beyond that, coordination overhead grows faster than throughput.
Headless mode turns Claude Code into a scriptable command
Headless mode runs Claude Code as a non-interactive command that prints a result and exits, which lets you call the agent from a shell script, a build step, or a CI job. Piping the contents of a build log into it and asking why the build failed is the simplest useful example: cat build.log | claude -p "why did this fail?" returns the diagnosis directly in the terminal, with no interactive window opening.
The command accepts a prompt on the command line, and standard input becomes part of the context. Adding a JSON output format makes the response machine-readable, and jq can then extract just the field a script needs. That pairing is what makes the agent usable inside existing automation rather than beside it.
Tool access is restrictable per call. Passing an allowed-tools argument limited to read limits what the invocation can do, which matters when a script runs unattended and you want read access only. The JSON payload also reports metadata such as turn count, duration in milliseconds, and a cost figure.
Treat that cost figure with care. On a subscription plan the number does not map to a bill you will receive, so it is useful for comparing runs and not for budgeting. On metered API access it is the actual charge, and the same script produces different economics.
The practical end state is a small triage script that calls the headless command, captures the result, and prints it, so a failure anywhere in your toolchain gets summarized the same way every time.
Checkpoints, session resume, and branching compared
Checkpoints, session resume, and conversation branching all restore earlier state, but they restore different things. Checkpoints restore files and conversation together inside one session; resume reopens a stored session; branching forks a conversation so you can try something risky without losing the original thread.
| Feature | What it restores | Command | Best used for |
|---|---|---|---|
| Checkpoints | Code and conversation state | /rewind | Undoing a bad multi-file edit |
| Resume | A previous session | --continue, --resume | Returning to yesterday's project work |
| Branching | A forked conversation | /branch | Trying a risky refactor safely |
| Named sessions | A findable session | -n plus a name | Running several workstreams in parallel |
A checkpoint records the state of the conversation at points along the way. After an agent renames symbols and breaks an interface, /rewind lists the earlier states and restores both the files and the conversation as they were, so you continue from a working baseline instead of repairing the damage by hand. The rewind menu offers each checkpoint by the prompt that produced it, and a restore applies the code and the conversation together. A tip calculator app broken by an interface-wide rename came back working after rewinding to the checkpoint before the rename, correct on the next input of 100.
Resume works at the session level. Sessions are stored locally with identifiers, and --continue reopens the most recent one in that project while --resume takes a specific identifier or name. Because the identifiers persist, a session started in one directory can be reopened from another, so the transcript of an earlier project is not tied to where you ran it.
Naming is the part that makes resume practical at scale. Starting a session with -n and a label such as off-refactor saves it under that name, which then works with --resume off-refactor, and the current session name stays visible in the status area while you work.
Branching splits the current conversation without overwriting it. That lets you ask for a destructive rewrite in the branch, inspect the result, then return to the original with /resume and continue the thread without the branch's changes. Since 2026-09-07 the practical value has been the same: explore without committing.
FAQ
- What are Claude Code advanced features? They are the configurable capabilities beyond basic prompting: custom subagents, skills, hooks, MCP servers, git worktrees, headless mode, checkpoints, session resume, and named sessions. Most live in project configuration files rather than in the prompt itself.
- Do subagents reduce Claude Code costs? They can, because a subagent's exploration stays inside its own context window and only the result returns to the main thread. Assigning a cheaper model to a subagent through its config file is the other lever.
- Are git worktrees required for parallel Claude Code agents? They are not enforced, but running two agents against one working directory invites conflicting edits. A worktree gives each agent its own files attached to the same repository history.
- Can Claude Code run without the interactive terminal? Yes. Headless mode accepts a prompt, reads standard input, prints a result, and exits, which makes it callable from shell scripts and automated jobs. Restricting allowed tools per call limits what an unattended run can do.
- How do you undo a bad Claude Code edit? Use the rewind command to return to an earlier checkpoint, which restores both the files and the conversation. Conversation branching offers a related option by forking a thread before a risky change.
From setup to repeatable workflow
The thread running through these features is context discipline. Subagents, skills, hooks, and worktrees all exist to keep the main conversation small, predictable, and free of work that should happen elsewhere. Gustavo dev doido has made a similar point about tooling: the value shows up when the setup removes repetition, not when it adds configuration.
A sensible order for a new project is subagents, then hooks, then worktrees, then headless mode. Subagents pay off immediately on review and debugging tasks, hooks prevent formatting drift, worktrees only matter once you actually run agents concurrently, and headless mode only matters once something else needs to call the agent.
If you have recorded a walkthrough of your own setup, the explanation already exists in spoken form and can be turned into an article. Skala Blog takes a YouTube URL, transcribes the video, and drafts it into a written piece you can edit and publish.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits