An advanced guide to
Claude Code

This is the single biggest tip I can give you and the one thing that will immediately improve your results. Previously, I would write lazy prompts like "add a dark mode toggle" and then get frustrated when Claude made a bunch of decisions that I didn't agree with. It would pick the wrong file, use the wrong component library, or change things that I didn't want to be changed.

Instead, you should spend the extra 30 seconds and be incredibly specific about what you want to happen. Tell Claude which files it should change, what components to reuse, and what not to touch. You'll immediately see the results improve and it'll mean there's less back-and-forth, which will save you time too.

When you're writing a prompt, try to include:

• File paths - use @filename to reference files directly, so that Claude reads them before responding. Or you can copy the specific path, like /components/footer.tsx
• Desired outcome - describe what the end result should look like
• Existing components - point to similar code that already exists in your project
• Constraints - mention anything that you don't want to be changed

You can also pipe data directly into Claude Code. Running cat error.log | claude will send the file straight into your conversation, which is really useful when you're sharing error logs or the build output.

Here's an example of a vague prompt versus a specific one:

The second prompt tells Claude exactly where to make changes, which components to reuse, how to store the state, and what not to break. It takes a few extra seconds to write, but it saves you from having to go back-and-forth correcting things.

By being specific from the very start, you'll get the results you want in the first 1-2 prompts and save yourself a lot of time.

Claude Code can also read images, which is an incredibly powerful way to improve your results - but most people aren't aware of this feature. If you're working on anything visual - such as a new UI component, screen layout, or any other design - pasting a screenshot into the conversation is far more effective than trying to describe what you want in words.

AI models have become incredibly good at analysing images and identifying key objects within them, so you should use this to your advantage. I've found that images are especially useful in two situations:

Showing what good looks like. If you have a design in Figma, a mockup from a designer, or even a screenshot of another site that has the style you're going for - paste it in. Claude can use it as a reference and build towards it, rather than guessing what you had in mind.

Showing what's broken. I've wasted a lot of time trying to describe visual bugs with text. "The dropdown is overflowing" doesn't give Claude much to work with. But if you attach a screenshot of the broken layout, Claude can see exactly what you're seeing and quickly fix the bug.

You can paste images directly into the Claude Code terminal or reference image files in your project. Either way, it will cut down on the back-and-forth messages and save you lots of time.

And here's the same view after Claude applied the fix:

Before you jump into writing code, it's worth asking Claude to explore your codebase and summarise what it finds. This is especially useful when you're picking up someone else's code, onboarding to a new project, or trying to understand how something works before you change it.

Claude is really good at reading files, searching for patterns, tracing imports, and building a picture of how things fit together. By doing this research upfront, you both have a shared understanding of the code before any changes are made - which leads to better decisions and fewer surprises.

This will give Claude an overview of your codebase and focus the results in future messages. It also means that Claude is less likely to duplicate components that already exist in your codebase, as it's able to spot and re-use them.

I've used this approach when investigating complex bugs that span multiple files and when I'm planning to do a refactor. Rather than having to read through dozens of files yourself, you can let Claude do the legwork and show a clear summary.

You can also use this to generate documentation. Just ask Claude to explore a module and write up how it works - it's a great way to create internal docs for parts of your codebase that have never been properly documented.

When you're trying to do a significant piece of work - whether it's a new feature, refactoring multiple files, or a bug that you haven't properly diagnosed - you should always use plan mode first. You can activate it by typing /plan or by pressing Shift+Tab to toggle it on.

In plan mode, Claude will explore your codebase, read any relevant files, and draft a plan before it writes any code. I've found this to be really valuable, as it gives Claude time to "think" and explore the problem in-depth. Plus, you a chance to see the plan and change course, before Claude goes and makes a bunch of changes that you didn't want.

I tend to use plan mode when:

After you've reviewed Claude's plan, you can approve it, ask for changes, or reject it entirely. This back-and-forth is far cheaper than having to undo a bunch of changes that went in the wrong direction.

That said, you don't use plan mode for everything. If the fix is small and you know exactly what needs to change, just ask Claude to do it directly. Planning will add some overhead and it's not necessary for those simple fixes.

But plan mode is only half the story when it comes to how you control Claude's reasoning. It decides when the thinking happens, but it doesn't decide how hard Claude reasons while it's writing the code.

A good way to think about this is breadth vs depth:

• Plan mode - use when you need to go broad into a problem
  e.g. when a problem touches multiple files, you want Claude to explore the codebase, or you need a wide view before committing to a direction
• Thinking mode - use when you need to go deep into a problem
  e.g. when you're focused on a specific problem or a tricky bug, and Claude needs more time to reason through it

By default, Claude will adjust this reasoning setting for you and will automatically "think" harder when it's facing a more complex task. If you want to change this yourself, you can run /effort and pick a level - the options are low, medium, high, xhigh, and max.

The higher levels will give Claude a bigger reasoning budget, but it will use more tokens and the response times will be longer. I typically leave mine on the default setting - then bump it up when I'm stuck on a genuinely hard problem and the default isn't getting me through.

The Model Context Protocol (MCP) allows Claude Code to easily connect with external tools, extending what it can do beyond just reading and writing files. MCP servers act as plugins that allow Claude to access databases, APIs, browsers, and plenty more - with the ecosystem growing really quickly.

To add an MCP server, just run claude mcp add from your terminal. Once you've got it configured, these servers will persist across sessions and Claude can use them automatically when needed. Here are some of the most useful ones I've come across:

The real power comes from combining multiple servers. You could ask Claude to read a Notion spec, pull the relevant Figma designs, build the feature, run end-to-end tests with Playwright, then open a PR on GitHub - all in a single conversation.

While most MCP servers extend what Claude can do, Playwright is a bit different because it allows Claude to actually see and automatically improve its own work. It's still pretty underused, but it's the first MCP I'd recommend for when you're doing UI work.

Claude will write the UI code for you, open it in a real browser and review the changes, then make improvements until it matches what you asked for. You don't need to constantly reload the page, or compare screenshots between each attempt - Claude can do it all for you.

To set it up, run claude mcp add playwright npx @playwright/mcp@latest to register the server, then npx playwright install to grab the browser binaries. One thing that's worth knowing - you should mention Playwright by name in your prompt, otherwise Claude might fall back and try to control the browser through Bash.

There are loads of useful workflows you can try, once you've got it running. You can ask Claude to review how a layout looks on different devices, walk through a checkout flow in plain English, or audit your app for accessibility issues. It's not free, as each screenshot and page read will lead to more tokens being used - but for UI work, it's the closest thing to having an extra pair of eyes on your screen.

If you're not a software engineer, you might not have heard about GitHub before. It's used by software teams to store their code, develop new features, and review each other's changes.

Each project sits in a "repository" (or "repo" for short), developers then propose a change through "pull requests" (PRs), and "issues" are used to report bugs or request new features. The team will then review these changes, add comments, and then approve it.

You can bring Claude into your GitHub workflow as a virtual teammate - allowing it to live inside your repo, pick up tasks when you tag @Claude in a comment, and keep things moving even when you're not at your laptop. This means that you can tag @Claude on a ticket on a Friday afternoon, head off for the weekend, and then come back to a draft PR.

You can also have Claude review every new PR as soon as it's opened, so that it can catch any obvious mistakes before they reach your team. To set it up, just run /install github app inside Claude Code and install it on your repo - two GitHub Actions will then be added automatically and can handle the rest.

These two GitHub Actions can be customised using the .github/workflows config files. You can also give Claude access to MCP servers inside the Action itself - so you could run Playwright for visual regression tests, or connect to Sentry and pull live errors into a PR review. It's worth noting that every tool permission has to be listed explicitly in the workflow, you can't have any wildcards or shortcuts for what Claude can access.

Bringing Claude into your GitHub workflow is incredibly useful for both teams and individuals - as you've essentially got an extra pair of hands that can pick up issues when you're working on something else, review PRs before they reach you, and (paired with a strict review checklist, which I cover when we get to slash commands) allows you to focus on the harder problems.

If you're going to be using Claude Code regularly on a project, you should create a CLAUDE.md file and store it in the root of your project. This file is automatically loaded into Claude's context at the start of every session, giving it constant knowledge about your codebase and how it's structured.

The easiest way to get started is to run /init inside Claude Code. It'll analyse your project and generate a starter CLAUDE.md file - which is based on how your codebase works, your test framework, and the patterns you use. It's not always perfect, but it will give you a solid foundation that you can improve over time.

You should think of it as onboarding documentation for an AI teammate. Without it, Claude will start every conversation from scratch and then has to figure out your project's conventions on its own - which will lead to more mistakes and more time spent correcting things.

A good CLAUDE.md file should include:

It's important that you keep the CLAUDE.md file concise. If your it gets too long, Claude will start ignoring half of it - so you should only keep the lines that prevent mistakes and cut everything else.

A nice way to improve your CLAUDE.md over time is to use memory mode. If you notice that Claude keeps making the same mistake, you can hit # directly in the chat and add a new rule. Claude will figure out the right CLAUDE.md to update (project, user-level, or a subdirectory file) and then add the rule for you. It means that you can add corrections as they happen, rather than trying to write the perfect version upfront.

You can also create CLAUDE.md files in subdirectories for instructions that are specific to one area. For example, a components/CLAUDE.md might describe your component patterns in more detail, while a tests/CLAUDE.md could explain your testing conventions.

If you find yourself typing the same prompts over and over, slash commands allow you to save these prompts and re-use them at another time. This means that you can write the perfect prompt once, and quickly invoke it again with a single command.

Here are some examples of where they're useful:

To do this, you simply create a markdown file inside .claude/commands/ at the root of your project. The filename will become the command - so review.md becomes /review. When you invoke the command, the file's content is immediately sent to Claude as the prompt.

The !`` syntax is quite useful, as it embeds the shell output directly into your prompt. When you run this command, Claude can automatically see the current git diff without you having to paste it in. This is what makes slash commands so powerful - they can pull in the latest context every time they're run.

Notice the $ARGUMENTS placeholder - this gets replaced with whatever you type after the command. So running /review payment-form.tsx will automatically include that filename in the prompt.

Since these command files live in your project directory, you can commit them to git and share these workflows with your team. It's a really powerful way to ensure there's consistency across the board - as everyone will run the same code review checklist, the same PR description template, and the same pre-commit checks.

You can also create personal commands in ~/.claude/commands/ for workflows that you want to make available across all of your projects. These show up as /command-name alongside any project commands, and are great for storing your personal preferences.

This ties in with what I said at the very start of this guide - the best prompts are specific and include plenty of detail. With slash commands, you can invest time writing the perfect prompt once and then reuse it forever. Once you've built a prompt that consistently gives you great results, you should save it as a command.

If slash commands are where you start automating your prompts, skills are the next step. They work in a similar way - they're reusable instructions you write once - but Claude applies them automatically when it recognises the task. This means that you don't need to type /review as often, because Claude can spot that you're asking for a review and load the skill on its own.

A skill is just a folder with a SKILL.md file inside. This file should have a name and description at the top, which tells Claude when it should use the skill, and then your instructions below. Here's what a simple one looks like:

The clever bit is how skills are loaded. When Claude Code starts up, only the names and descriptions sit in your context - which means you can have dozens of skills available without bloating the context window. When you ask Claude to do something, it matches your request against the descriptions and asks you to confirm before loading the full body of the relevant skill. That's what makes skills much cheaper context-wise than putting everything in CLAUDE.md.

Skills live in two places:

• Personal skills - live in ~/.claude/skills/ and follow you across every project
  e.g. your preferred commit message style, documentation format, or test patterns
• Project skills - live in .claude/skills/ and get shared with your team through git
  e.g. your team's code review checklist, PR description format, or component conventions

The description is the most important field, because it's what Claude uses to decide whether to load the skill. A good description should answer two questions - what does the skill do, and when should Claude use it? If you write a vague description, Claude won't be able to trigger the skill reliably. You should also include the words that you'll likely use, when you're prompting Claude and want the skill to fire.

There are a couple of advanced techniques that you should know about:

• allowed-tools - allows you to restrict what Claude can do when a skill is active, which is really useful for security-sensitive skills. For example, a code-review skill should only be allowed to read files and run git commands, it should never edit or write files automatically
• Progressive disclosure - useful when a skill grows beyond a single file. You should keep your SKILL.md under 500 lines and move any longer information into subfolders like references/, scripts/, or assets/. Claude will only load these extra files when it actually needs them, which prevents your context window from becoming bloated

Knowing when to use a skill versus a CLAUDE.md rule can be a bit confusing at first, so here's how I like to think about it:

If it's a simple instruction that should always apply, you should add a rule to the CLAUDE.md file. For example, we added the "you should always use the term tasting notes, not flavours" rule earlier.

If it's a more complex instruction that's only relevant some of the time, you should create a skill. The accessibility audit above is a good example, as it will only be trigged when we add a new webpage - rather than every time we make a minor change.

With hooks, you can ensure that Claude will always do certain things, without you having to ask. They're a bit more technical to set up than skills or slash commands, but they're also much more powerful - as they run automatically at specific points in Claude Code's lifecycle and can even block actions if needed.

Anthropic supports different types of hooks, which can be run at different times:

The most common use case is auto-formatting. A PostToolUse hook can run Prettier (or whichever formatter you use) every time Claude edits a file - so that your codebase stays consistent without you having to think about it. You could write this as a rule in CLAUDE.md and Claude would usually follow it, but a hook makes sure that it happens every time.

Another common use case is blocking things you don't want Claude to do. You can use the PreToolUse hook to automatically inspect a tool call before it runs and decide whether to allow it. If your hook exits with code 2, the action is blocked and an error message is sent back to Claude - so that it knows why this action was blocked and can adjust its plan.

This is useful for any hard rules that you want enforced, rather than mere suggestions for the AI:

• Block commits directly to the main branch
• Block edits to specific files - e.g. production configs, secrets, lock files
• Stop risky commands from being run by Claude - such as rm -rf
• Run your linter after every edit and send errors directly to Claude

To setup your own hooks, you can use the /hooks command inside Claude Code, or edit the .claude/settings.json file directly. Since the settings file lives in your project, you can commit these hooks to git and share them with your team.

Hooks add quite a bit of overhead and complexity, so you should only use them for things that genuinely need to happen every time without fail. Otherwise, you're better off with a skill or a slash command - which are more lightweight and flexible, as they can be triggered when needed and won't run with every single Claude interaction.

Subagents are incredibly useful for large or complicated tasks. Each subagent will run in a separate context window from your main conversation, which allows Claude to break the work into smaller chunks, explore your codebase in more detail, and only return the final summary to your main thread. Any intermediate steps that the agent does - such as reading files, or performing web searches - stay within the subagent's context and won't clutter your main thread.

You should use subagents when the task is:

• Substantial - it's big enough that delegating makes sense, rather than a quick question you could just ask in your main thread
• Focused - Claude can handle it in one pass, without needing repeated back-and-forth to make progress
• Self-contained - the subagent only ever sees the brief, so the task shouldn't depend on the rest of your conversation to make sense

They're not worth it for quick questions, and they don't work well when the task needs Claude to see everything together - like understanding writing style across loads of content, or a refactor where each step informs the next. In those cases, splitting the work across subagents doesn't make sense - as Claude is losing the subtle context it needs to perform well.

Here are some of the more common subagents people build:

.claude/agents/
├── test-runner.md           # runs the test suite and returns just the failures
├── readme-generator.md      # reads a project and writes a clean README
├── dependency-auditor.md    # scans for outdated or vulnerable dependencies
├── migration-planner.md     # produces a step-by-step migration plan
└── brand-voice-reviewer.md  # rewrites text in your brand's voice

Of course, you don't need to build all of these yourself. Claude Code has several built-in subagents that can handle the common tasks, which you can use straight away:

But you'll get more out of subagents by creating your own. Just run /agents inside Claude Code and it'll walk you through the setup. You can choose the scope (whether the subagent is specific to this project, or should be available for all your projects), the tools it can use, the model that powers it, and a colour so it's easy to spot within the UI.

It's worth knowing that the description field does two things, not one. It controls when Claude launches the subagent, but it also shapes the input prompt that Claude writes for it. So if you add something like "You must tell the agent precisely which files or area of the code to review" to the description, the parent agent will start writing more specific launch prompts. Small tweaks to the description can make a noticeable difference to how the subagent performs.

There are four patterns that make subagents reliable:

It's unlikely that the first version of your subagent will be perfect, so you'll need to make some tweaks after you see how it performs in the real world. You might need to make minor changes to the description or output structure, until you're happy with everything - so don't expect that you'll get it right first time.

Every AI model has something called a "context window", which holds your entire conversation and allows Claude to have a better picture of what you want to do. It includes every message that you send, every file that Claude has read, and every tool that it has called.

Over time, this context window starts to fill up and you'll notice that the model's performance starts to drop off. Claude might forget some of your earlier instructions, make more mistakes, and the whole session starts to feel a bit slower. So whenever you're working on a long session with Claude, you need to keep your context window in mind and be ready to clear it.

Here are a few commands that you can use to manage your context window and improve Claude's performance over long sessions:

• /clear - wipes the context completely. Use it when you're switching to an unrelated task, or starting fresh after you've added a new feature
• /compact - summarises the conversation so far, which frees up space and preserves the key decisions. You can also focus the compaction with something like /compact focus on the API changes, which keeps the parts that matter and drops any noise

I tend to use /clear whenever I can, especially when we don't need to carry forward context for the next task. /compact is the right choice when you want to keep going on the same thread but you're running out of room.

Anthropic has recently added auto-compact to Claude Code, which automatically compacts your conversation when it becomes too long. It's a useful safety net, but it loses some of the detail and nuance from your earlier conversation - so it's not as effective as clearing the context yourself.

Sometimes Claude will head off in a direction that you didn't intend, and the fastest fix is to undo rather than ask it to remove the code. There are two commands that can handle this:

• Esc - interrupts Claude mid-action if you see it going off track. Your context is preserved, so you can redirect it without losing what came before
• Esc + Esc (or /rewind) - restores your code and conversation to an earlier checkpoint. Whenever Claude Code does an action, it creates a checkpoint - allowing you to easily roll back the changes it made

When Claude gets something wrong, it's perfectly normal to correct it and try again. That works a few times - but after lots of failed attempts, the conversation starts to fill up with bad approaches and Claude only becomes more confused with each one.

/rewind is the better tool for this, as it allows you to return to a previous state and try again with a better prompt. It's also faster than using /clear because you don't lose the rest of the conversation, and you can stop the mistakes from compounding.

After using Claude Code for a while, you find that you're waiting on one big task to finish and then realise that you could have kicked off several small jobs in parallel. For example, you could have asked Claude to rewrite a README, fix a bug on another page, and add the unit tests that you've been putting off.

However, running two Claudes on the same project folder can add issues - as the models can trip over each other's file edits, leave the codebase in a broken state, and you might spend more time untangling conflicts than you would have writing the code yourself.

To solve this, you should be using Git worktrees. If you're unsure what this is, a worktree is a separate folder that has contains a copy of your project and sits on its own branch. This is essentially Git's term for a parallel version of your code, which won't affect the others until you merge it back. Each Claude gets its own worktree, can work away in isolation, and you then merge the changes back when each one finishes.

The good news is that Claude Code has all of this built in for you. Simply add --worktree feature-x (or -w feature-x for short) when you launch Claude in the Terminal and it'll set up an isolated worktree on its own branch, then drop you straight into a fresh Claude session inside it.

Once you've done that, you should open another terminal, and run the command again with a different name. You've now got a second Claude working in parallel, completely separate from the first.

It's worth noting that a worktree is a fresh checkout, so any untracked files - like .env or .env.local - won't be there by default. If you have files that you need in every worktree, you should list them in a .worktreeinclude file at the root of your project (it uses the same syntax as .gitignore) and Claude Code will copy them in for you.

This also pairs nicely with subagents. You can add isolation: worktree to a custom subagent's frontmatter and each one will run in its own temporary worktree - allowing you to hand off a heavy investigation and have it running in the background, without it ever touching your main project files.

If you're using the Claude desktop app, this all happens automatically - every new session is given its own worktree, so you don't need to change any settings or add the --worktree flag.

Overall, this changes where the bottleneck is. It's no longer "how fast can Claude work", it's now "how many Claudes can I keep track of at once?". Running three parallel Claudes isn't actually three times faster, if you can't review their work fast enough and are becoming overwhelmed. I find that two or three is the sweet spot, but it really depends on the complexity of what each one is doing.

Multiple Claude sessions work really well when the tasks are completely separate - like one Claude that is changing the UI, one that's improving the API, and another that's writing unit tests. But it doesn't work as well when the tasks need to coordinate or share state. In those situations, you should keep everything in a single conversation so that Claude can keep the context it needs.

I've been using Claude Code for the last year and it's an abolute joy to use. We now have access to an incredibly powerful tool that allows anyone to write code, fix issues in minutes, and design new user experiences that delight people.

During this time, I've really put Claude Code through its paces and given you lots of strategies for getting the most from it. Here's a quick overview of the different topics we've covered in this guide:

Claude Code is one of the most exciting tools I've used in years. It's allowed me to do things faster than ever, fix issues in minutes, and build products that wouldn't have been possible before. Hopefully, the techniques in this guide will help you get to just as much out of the tool - and enjoy using Claude Code as much as I do.

If you found this guide useful, you'll enjoy my weekly newsletter - every week I analyse the latest AI advances and how you can use them. It's free and you can unsubscribe at any time.

Loop Newsletter

Get weekly AI insights delivered
to your inbox

Subscribe for free

Read by executives at: