# Advanced Claude Code: the power-user techniques

Once you are past the basics, Claude Code stops being a single chat box and becomes a control panel. There is a technique for directing the model, a technique for extending it, a technique for running work in parallel, a technique for managing what it remembers, and a technique for undoing what it did. This guide is the reference for all of them.

The companion to this one is [how top developers use Claude Code](/guides/how-top-developers-use-claude-code), which covers the habits and the mindset. This guide is the mechanics: one tight section per technique, what it does, and exactly how you invoke it from the CLI or config. Skim it once, then come back to the cheat sheets when you need the exact incantation.

Anything version-specific is hedged, because the tool moves fast. When a flag or shortcut matters to you, confirm it against the official docs at [code.claude.com/docs](https://code.claude.com/docs).

## The five jobs of a power user

Every advanced technique falls into one of five buckets. Hold this map in your head and the rest of the guide organises itself.

The casual user only ever does the implicit version of the first bucket: type a prompt, accept the output. The power user reaches for the right tool in each bucket at the right moment.

## Direct the model

This is about controlling *how* Claude approaches a task before it starts, not correcting it after.

### What is plan mode in Claude Code?

Plan mode puts Claude in a read-only stance: it explores the code and proposes a plan, but does not edit anything until you approve. You enter it by pressing `Shift+Tab` to cycle modes, or with the `/plan` command. Reviewing a wrong plan is far cheaper than reviewing wrong code, so reach for this on anything touching more than a couple of files.

The format you ask for matters. A numbered plan with a one-sentence rationale per step makes thin reasoning easy to spot.

Stay in plan mode. Give me a numbered plan with one sentence of rationale per step, and flag any file you are unsure about. Do not edit anything until I approve.

If step three says it will touch a file you know is shared with three other services, you catch that now, for free, instead of after the agent has built two hundred lines on top of the wrong assumption.

### Model selection

Different models trade speed for depth. Switch with `/model`, then pick the one that fits the task: a fast model for mechanical edits, a stronger one for architecture or subtle bugs.

```bash
/model
```

Switching models mid-session is fine, but note it invalidates the prompt cache (see the caching section below), so do it at task boundaries when you can.

### What do effort levels do?

Effort controls how much reasoning the model spends per turn. Higher effort means deeper thinking at the cost of more time and tokens. It is not "better" by default. On a rename, high effort buys you nothing.

```bash
/effort low
```

```bash
/effort high
```

The accepted values, lowest to highest, are below. The full breakdown lives in [effort levels](/guides/claude-code-effort-levels).

| Level | Use it for |
| --- | --- |
| `low` | Renames, small edits, mechanical changes |
| `medium` | Everyday feature work |
| `high` | Refactors with many dependents, real debugging |
| `xhigh` | Subtle concurrency or correctness problems |
| `max` | Cross-system architecture and design |

Set effort at the *start* of a task, not when the agent is already stuck. Like model switches, changing effort resets the prompt cache.

## Extend Claude

These techniques add new capabilities or wire deterministic behaviour around the model.

### Custom slash commands and skills

A custom command is a reusable prompt you invoke on demand. A skill is a reusable playbook Claude pulls in when a task matches. Both live in your project's `.claude/` directory. The key part: they load *on demand* rather than at startup, so they cost you nothing until used.

The on-demand loading is the part power users exploit. You can have dozens of commands and skills sitting in `.claude/` and pay no context cost for the ones you do not invoke. So the right move is to encode every repeated workflow you have, not to ration them. Anything you have typed by hand more than twice is a candidate.

```markdown
Run the test suite, then summarise only the failures: test name, file, and a
one-line guess at the cause. Do not fix anything yet.
```

Save that as `.claude/commands/triage.md` and `/triage` runs it. Skills live under `.claude/skills/` as a `SKILL.md` with a short description. The deep dive is [commands and skills](/guides/claude-code-commands-and-skills).

### What is a hook in Claude Code?

A hook is a shell script wired to a lifecycle event. It runs *deterministically*, regardless of what the model decides, which makes hooks the right tool for guardrails, auto-formatting, and forced tests. The model can be talked out of a rule. A hook cannot.

Common events you can hook:

| Event | When it fires |
| --- | --- |
| `SessionStart` | Once when a session opens |
| `UserPromptSubmit` | When you submit a prompt, before Claude reads it |
| `PreToolUse` | Before any tool runs (can block) |
| `PostToolUse` | After a tool succeeds (can rewrite output) |
| `Stop` | When the agent finishes its turn |

A `PostToolUse` hook on writes that runs your formatter eliminates a whole class of follow-up prompts. The full mechanics, exit codes, and config are in [hooks and guardrails](/guides/hooks-and-guardrails).

The power-user distinction between a skill and a hook: a skill *guides* the model and the model chooses when to follow it; a hook *forces* behaviour and the model has no say. If a thing must happen every time, a formatter, a test gate, a block on force-pushing, use a hook. If a thing is a strong default the model should usually follow, use a skill or a memory rule.

### MCP

MCP connects Claude to external tools and data: a database, an issue tracker, a docs server. Each MCP server exposes a set of tools the agent can call.

Two things power users care about. First, manage servers from `/mcp` to see what is connected. Second, tool definitions can be *deferred*, or loaded on demand, so a server with fifty tools does not flood your context with fifty schemas before you use any of them. Connecting or disconnecting an MCP server resets the prompt cache, so treat it as a task-boundary action.

```bash
/mcp
```

Every connected tool whose definition is loaded eagerly is tokens spent before you have asked a question. Connect the servers a task needs, lean on deferred loading for the rest, and disconnect what you are done with at a task boundary rather than mid-flow.

## Run work in parallel

When a job splits into independent pieces, doing them one after another is the slow way. These three techniques run work concurrently, and they solve subtly different problems: subagents protect your context, worktrees protect your files, and background tasks protect your time. Knowing which problem you have tells you which one to reach for.

### What is a subagent?

A subagent is a specialised helper with its *own fresh context window*. It does a scoped job and returns a summary, which keeps your main context clean. This is the key insight: the subagent reads ten files, but your main session only receives the three-line conclusion, not the ten files.

Use subagents when a task needs deep exploration whose intermediate output you do not want polluting the main thread: a focused search, a code review, an audit of one area.

| Good subagent job | Why |
| --- | --- |
| Find every call site of a function | Reads many files, returns one list |
| Review a diff against conventions | Heavy reasoning, returns a verdict |
| Audit one module for a pattern | Scoped, parallelisable, summary out |
| Research how a library is used | Lots of reading, little to keep |

The anti-pattern is delegating something whose full output you need in the main thread. If you want every line, do it in the main session; a subagent will hand you a summary and the detail is gone.The seductive mistake is delegating the edit itself, not only the research, then asking the subagent "what exactly did you change?" You get a paraphrase of a paraphrase, because the diff lived and died in a context you cannot see. Send subagents to read, search, and report; keep any change whose lines you will need to review in your own session.

### Parallel agents and git worktrees

To run *several* agents at once without them clobbering each other's files, give each its own git worktree. A worktree is an isolated checkout of the same repo, so agent A editing `src/auth/session.ts` cannot collide with agent B editing the same file.A fresh worktree has no installed dependencies, so an agent runs tests against a half-broken checkout and reports phantom failures. Install or symlink each worktree's deps (and copy any local env file) before you fan agents into it.

A *fan-out* or batch decomposes one large job into many independent units, each running in its own worktree, then merges the results.

The rule of thumb: if two pieces of work could go to two developers with no handoff meeting, they can fan out. If they must agree on a shared interface first, do that interface work, then fan out. See [how agents fan out](/guides/how-agents-fan-out) and [isolate parallel agents with git worktrees](/guides/isolate-parallel-agents-with-git-worktrees).

Parallelism does not remove the review step, it multiplies it. Three agents produce three diffs, and each one needs the same scrutiny a single diff would. Review them as they land rather than letting them pile up, and merge in an order you control. The speed win is real, but it is a win on the work, not on your attention. You still read every diff.

### Background tasks

Long-running work can be detached so it runs in the background while the session keeps moving. A slow test suite. A build. A watch process. You start the task, send it to the background, and continue working. Claude surfaces the result when it finishes instead of blocking the conversation while it runs.

The combination that compounds: kick off the slow suite in the background, fan out the independent edits across worktrees, and review each diff as it lands. The session is never idle waiting on one slow thing, because the slow thing is detached and the parallel work fills the time.

## Manage context

The context window is a budget. Spend it on what matters for the current task and nothing else. A bloated context produces a drifting, anchored agent that keeps surfacing decisions from earlier in the session that no longer apply. The techniques here are how you keep the budget lean: measure it, trim it mid-task, or reset it entirely between tasks.

### Inspect with /context

Before you optimise, measure. `/context` shows where your token budget is going: system prompt, memory files, tools, conversation history.

```bash
/context
```

Read the breakdown like a budget. If memory files are eating a large slice, your `CLAUDE.md` has grown bloated and needs trimming. If tools dominate, you have too many MCP servers connected for this task. If history dominates, you are overdue a `/compact` or a `/clear`. The agents people call "dumb" or "drifting" are almost always running in a context full of stale history nobody cleared.

### What is the difference between compact and clear?

Two ways to reclaim context, for two different moments.

| Command | What it does | When |
| --- | --- | --- |
| `/compact` | Summarises the conversation so far and continues | Mid-task, context filling up, you are not done |
| `/clear` | Wipes the conversation, fresh start | Switching to an unrelated task |

`/clear` is not losing work: your code is in the files. The conversation is just the agent's short-term memory, and a clean one is a focused one. Reach for `/compact` only when you need to keep the thread. Note that compacting resets the prompt cache.

```bash
/clear
```

A reliable rhythm: treat each task as its own session. Open a clean context, do one focused piece of work, clear, start the next. When you blur the boundary and let a refactor drift into a bug fix and then a new feature, you are paying context cost for history that no longer helps, and you are inviting the agent to carry a stale assumption from the old task into the new one. The boundary between tasks is the cheapest place to reset.

### Resume a session

Clearing is for starting fresh, but sometimes you want the opposite: the thread you closed an hour ago. Resume the most recent session, or pick an older one from a list.

```bash
claude --continue
```

```bash
claude --resume
```

`--continue` picks up your last session where you left off. `--resume` shows a list so you can choose a specific past conversation. Use these when you closed the terminal mid-task and want the context back, rather than re-explaining everything to a clean session.

### Auto memory

Claude can persist learnings across sessions in memory files so it does not re-derive the same context every time. When you catch the agent making the same wrong call twice, that is a convention worth writing down once. For how the layers fit together, see [how Claude Code memory works](/guides/how-claude-code-memory-works) and [session state](/guides/claude-code-session-state).

Memory and context pull in opposite directions, and balancing them is the skill. Memory is the context you *want* loaded every session: your conventions, your stack, your hard rules. Conversation history is the context that *accumulates* whether you want it or not. Keep memory tight and deliberate, and clear or compact history aggressively. A bloated memory file is just as expensive as a bloated conversation, and it costs you on every single session instead of one.

## Safety and recovery

Even with plan mode and review, you will sometimes accept a change you regret. The power-user stance is not to never make mistakes, it is to make recovery cheap and routine. When undoing is one keystroke, you can afford to let the agent try bolder things, because a bad outcome costs you seconds. Recovery is a first-class technique, not a panic move.

### Checkpointing and rewind

Claude Code checkpoints your files as it works. To undo edits made within a session, press `Esc` twice or run `/rewind`, and step back to an earlier state. This is *local* session history, not git: it works even on files you never committed, and it does not touch your git log.

```bash
/rewind
```

Rewind and git are complementary. Rewind is for "undo the last few edits in this session." Git is for durable, shareable history. Use rewind for fast in-session recovery; commit at real milestones.

Three forms of isolation get confused, so here is the line between them:

| Mechanism | Isolates | Survives session? |
| --- | --- | --- |
| Rewind | Your file edits, in time | No, session-local |
| Worktree | One agent's files from another's | Yes, it is a real checkout |
| Subagent | One agent's context from yours | No, returns a summary |

Rewind is undo across time. A worktree is separation across space. A subagent is separation of attention. Power users use all three, often in the same task.

## Keep the prompt cache warm

Claude Code caches the stable prefix of your context automatically, which makes repeat turns cheaper and faster. You do not turn it on; your job is to avoid throwing it away. The cache invalidates when the prefix changes, so a handful of actions reset it.

| Action | Resets cache? |
| --- | --- |
| Switching model (`/model`) | Yes |
| Changing effort (`/effort`) | Yes |
| Toggling fast mode | Yes |
| Connecting or disconnecting MCP | Yes |
| `/compact` | Yes |
| Sending another normal turn | No |

The practical move: batch your cache-busting changes. Pick the model and effort at the *start* of a task and leave them, rather than flipping mid-flow and paying to rebuild the cache each time. The full mechanism is in [prompt caching](/guides/prompt-caching).

Note that the cache is a convenience, not a constraint. If switching model or effort is the right call for the task, switch. Paying to rebuild the cache once is cheaper than running the wrong model for an hour. The waste to avoid is the *needless* flip, the one that buys you nothing, not the deliberate one.

## Headless mode

Every technique so far assumes a human at the keyboard. Headless mode is what you reach for when there is not one. For automation, CI, or scripting, run Claude non-interactively with `-p` (print). It takes a prompt, does the work, prints the result, and exits. No chat loop.

```bash
claude -p "summarise the open TODOs in src/ and group them by file"
```

This is how you wire Claude into a pipeline: a pre-commit summary, a scheduled audit, a CI step that comments on a diff. Pair it with hooks and a tight `deniedTools` list so an unattended run stays inside its lane.

| Headless job | Where it runs |
| --- | --- |
| Comment on a pull request diff | CI on every PR |
| Summarise the day's changes | A nightly scheduled task |
| Triage failing tests into a report | A post-test CI step |
| Draft release notes from commits | A release pipeline |

The rule for unattended runs: an agent that nobody is watching needs guardrails that nobody has to watch either. Restrict its tools, block the destructive patterns with a hook, and never mount production credentials into the run.

## Which technique for which situation

The hard part is not knowing the techniques, it is reaching for the right one in the moment. This maps a symptom to the fix.

| Situation | Reach for |
| --- | --- |
| About to touch many files | Plan mode |
| Task is mechanical and cheap | `/effort low` |
| Task is subtle or cross-system | `/effort high` or `max` |
| You repeat the same prompt weekly | Custom command |
| A rule must hold every single time | Hook |
| Agent needs data it cannot see | MCP server |
| A scoped job would flood context | Subagent |
| Several independent edits at once | Worktrees, fan out |
| A slow build is blocking you | Background task |
| Session feels sluggish or off | `/context`, then `/compact` |
| Switching to unrelated work | `/clear` |
| Want a closed session back | `claude --continue` or `--resume` |
| You just accepted a bad edit | `/rewind` |
| Wiring Claude into CI | Headless `-p` |

## The full cheat sheet

| Technique | Invoke | One-line purpose |
| --- | --- | --- |
| Plan mode | `Shift+Tab` or `/plan` | Propose before editing |
| Switch model | `/model` | Trade speed for depth |
| Set effort | `/effort low\|medium\|high\|xhigh\|max` | Tune reasoning per task |
| Custom command | `/your-command` | Run a saved prompt |
| Skills | auto, from `.claude/skills/` | Loaded when a task matches |
| Hooks | events in `settings.json` | Deterministic guardrails |
| MCP | `/mcp` | Connect external tools |
| Subagent | delegate a scoped job | Fresh context, returns a summary |
| Worktrees | one per parallel agent | Isolated, no file clobbering |
| Background task | detach long work | Session keeps moving |
| Inspect context | `/context` | See token usage |
| Compact | `/compact` | Summarise and continue |
| Clear | `/clear` | Fresh start between tasks |
| Resume | `claude --continue` or `--resume` | Pick a session back up |
| Rewind | `Esc` `Esc` or `/rewind` | Undo session edits |
| Headless | `claude -p "..."` | Non-interactive run |

## Putting it together

Here is a single workflow that chains several of these into one tight loop. Say you are doing a real refactor across an auth module and its tests.

You open the repo and set up before you ask for anything. Pick the model and effort once, at the start, so the cache stays warm for the whole task.

```bash
/effort high
```

You enter plan mode with `Shift+Tab` and describe the change.

Refactor the session store to use the new idempotency key pattern. Stay in plan mode. Give me a numbered plan with one sentence of rationale per step, and flag any file you are unsure about.

You read the plan, cut a step that was out of scope, and approve. The work splits cleanly into independent pieces, so you fan it out: one agent updates the store in `src/auth/session.ts`, another updates the client hooks, a third regenerates the tests, each in its own worktree so they cannot collide. A `PostToolUse` hook formats every file as it is written, so you never review a style nit.

While the slow integration suite runs in the background, you review the three diffs as they land. One agent removed a guard it judged redundant. You catch it, and rather than re-prompting from scratch you rewind that file to before the edit and correct it in context. When everything is green, you commit at the milestone, then run `/clear` and start the next task with a clean context.

That is the power-user loop: direct the model up front, extend it with hooks, run the independent work in parallel, keep the context lean, and lean on rewind when something slips. None of these techniques is hard on its own. Chaining them is what separates a power user from someone typing one prompt at a time.

## Anti-patterns to avoid

The techniques cut the other way when misused. A few to watch for:

- **Max effort on everything.** It is slower and costs more for no gain on simple work. Match effort to the task.
- **Flipping model and effort mid-task.** Every flip resets the cache. Decide up front, then leave them.
- **Never clearing context.** History accumulates and the agent drifts. Clear between tasks, compact within them.
- **Fanning out coupled work.** If two pieces share an interface, parallel agents will each invent their own. Settle the interface first.
- **Delegating to a subagent when you need the detail.** You get a summary back, not the lines. Keep work in the main thread when you need to see all of it.
- **Trusting instructions where a hook belongs.** If a rule must hold every time, a confident model can still talk itself out of an instruction. A hook cannot be talked out of anything.

For the mindset behind all of this, read [how top developers use Claude Code](/guides/how-top-developers-use-claude-code). For the exact mechanics of any single technique, follow its link above or check the docs at [code.claude.com/docs](https://code.claude.com/docs).