# Claude Code Cookbook

## Claude Code Cookbook

Practical patterns for getting the most out of Claude Code, adapted from Boris Cherny's (@bcherny) field-tested workflows shared in January and March 2026. Compiled by [AI For Global Education](https://aiforglobaleducation.org/) as part of our commitment to responsible, practical AI adoption in education and beyond.

***

### Where You Run Claude Code

Claude Code runs across five surfaces: the terminal (CLI), the web at [claude.ai/code](https://claude.ai/code), inside your IDE via native extensions for VS Code, Cursor, Windsurf, and JetBrains, the Claude Desktop app, and the Claude mobile app for iOS and Android. The patterns in this cookbook apply across all of them. Your `CLAUDE.md`, slash commands, agents, hooks, MCP configs, and permissions are all workspace-level settings stored in your repo's `.claude/` directory, so they follow you regardless of which surface you use.

You can move sessions freely between these surfaces. Run `claude --teleport` or `/teleport` to continue a cloud session on your local machine. Run `/remote-control` to control a locally running session from your phone or browser. If you find yourself doing this often, set "Enable Remote Control for all sessions" in `/config` so every session is accessible remotely by default.

The CLI and the VS Code extension share conversation history. You can start a session in the extension and resume it in the terminal with `claude --resume`, or vice versa. If you are working in an external terminal, run `/ide` inside Claude Code to connect it back to your open VS Code window.

The mobile app is a genuine coding surface, not just a monitoring tool. You can write and land code from your phone without opening a laptop. Download the Claude app for iOS or Android and use the Code tab on the left.

The recipes below are written from a terminal-first perspective (that is where Boris Cherny's tips originate), but Section 13 covers IDE-specific features and Section 14 covers Desktop-specific features that layer on top of everything else.

***

### 1. Run Multiple Claudes in Parallel

Don't limit yourself to a single Claude Code session. Run five instances in parallel across numbered terminal tabs (1 through 5), and enable system notifications so you know when any instance needs your input. In VS Code, you can also open multiple conversation tabs within the extension itself, giving you a visual overview of all your active workstreams.

You can also run 5 to 10 additional sessions on [claude.ai/code](https://claude.ai/code) alongside your local terminal instances. Hand off work between local and web sessions freely, kick off new sessions in Chrome, and even start sessions from the Claude iOS app on your phone to check in throughout the day.

For serious parallel work within a single repository, use git worktrees (see Section 15).

{% hint style="info" %} Parallelism lets you keep multiple workstreams moving without context-switching. While one Claude is running tests, another can be refactoring, and a third can be working on docs. {% endhint %}

***

### 2. Use the Best Model with Thinking Enabled

Use Opus with thinking enabled for everything. Even though it is bigger and slower than Sonnet, you have to steer it less and it is better at tool use, making it almost always faster in practice than using a smaller model.

{% hint style="info" %} A slower, smarter model that gets things right the first time beats a faster model that needs multiple correction cycles. {% endhint %}

***

### 3. Invest in Your CLAUDE.md

Your team should share a single `CLAUDE.md` file for the repo. Check it into git. The whole team should contribute to it multiple times a week. Any time Claude does something incorrectly, add that learning to the `CLAUDE.md` so it knows not to repeat the mistake.

Example `CLAUDE.md` structure:

```markdown
# Development Workflow

**Always use `bun`, not `npm`.**

# 1. Make changes

# 2. Typecheck (fast)
bun run typecheck

# 3. Run tests
bun run test -- -t "test name"       # Single suite
bun run test:file -- "glob"          # Specific files

# 4. Lint before committing
bun run lint:file -- "file1.ts"      # Specific files
bun run lint                         # All files

# 5. Before creating PR
bun run lint:claude && bun run test
```

The `CLAUDE.md` is a living document that captures your team's accumulated knowledge about how Claude should work within your specific codebase.

***

### 4. Use Code Review to Grow CLAUDE.md

During code review, tag `@claude` on your coworkers' PRs to add new rules to the `CLAUDE.md` as part of the PR itself. Use the Claude Code GitHub action (`/install-github-action`) for this.

For example, if you spot a pattern issue in a PR review:

> nit: use a string literal, not ts enum\
> @claude add to CLAUDE.md to never use enums, always prefer literal unions

This is a form of "Compounding Engineering": every review cycle makes Claude permanently smarter about your codebase.

***

### 5. Start Sessions in Plan Mode

Most sessions should start in Plan mode (toggle with `shift+tab` twice in the terminal, or click the mode indicator in VS Code). If your goal is to write a Pull Request, stay in Plan mode and go back and forth with Claude until you are happy with the plan. From there, switch into auto-accept edits mode and Claude can usually one-shot the implementation.

{% hint style="info" %} A good plan is the highest-leverage input you can provide. It aligns Claude's understanding with your intent before any code is written, dramatically reducing wasted cycles. In VS Code, Plan mode is even richer: Claude's plan opens as an editable markdown document where you can leave inline comments before execution begins. {% endhint %}

***

### 6. Create Slash Commands for Repeated Workflows

Use slash commands for every "inner loop" workflow that you perform many times a day. This saves you from repeated prompting and makes it so Claude can use these workflows too. Commands are checked into git and live in `.claude/commands/`.

For example, a `/commit-push-pr` command that handles the full commit, push, and PR creation flow in one step.

{% hint style="info" %} If you find yourself typing the same kind of prompt more than twice, turn it into a slash command. {% endhint %}

***

### 7. Use Custom Agents

Custom agents are a powerful primitive that often gets overlooked. Define a new agent in `.claude/agents/`, then run it with `claude --agent=<your agent's name>`. Each agent gets its own system prompt, colour label, and can be restricted to specific tools.

Examples of useful agents:

* **code-simplifier** -- Simplifies code after Claude is done working on it
* **verify-app** -- Has detailed instructions for testing Claude Code end to end
* **ReadOnly** -- Restricted to the Read tool only, so it cannot edit files or run bash. Useful for safe exploration of unfamiliar codebases

Example agent definition (`.claude/agents/ReadOnly.md`):

```markdown
---
name: ReadOnly
description: Read-only agent restricted to the Read tool only
color: blue
tools: Read
---

You are a read-only agent that cannot edit files or run bash.
```

Think of agents as specialised roles. The main Claude session is your generalist; agents handle specific jobs with tighter constraints or tailored instructions. See [code.claude.com/docs/en/sub-agents](https://code.claude.com/docs/en/sub-agents) for the full reference.

***

### 8. Use Hooks Across the Agent Lifecycle

Hooks let you run deterministic logic at specific points in Claude's lifecycle. The `PostToolUse` hook for formatting code is just one example. The full set of hook points gives you much finer control over how Claude behaves.

PostToolUse to auto-format code after every write or edit:

```json
"PostToolUse": [
  {
    "matcher": "Write|Edit",
    "hooks": [
      {
        "type": "command",
        "command": "bun run format || true"
      }
    ]
  }
]
```

The `|| true` ensures the hook does not block Claude if the formatter encounters an issue.

Other hook points to consider:

* **SessionStart** -- Dynamically load context each time you start Claude. Useful for injecting environment-specific data or pulling fresh state from external systems.
* **PreToolUse** -- Log every bash command the model runs. Good for audit trails and debugging.
* **PermissionRequest** -- Route permission prompts to WhatsApp (or another channel) for you to approve or deny remotely. Especially useful when Claude is running autonomously and you are away from your machine.
* **Stop** -- Poke Claude to keep going whenever it stops. This turns Claude into a more persistent worker that only pauses when it genuinely needs input.

See [code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks) for the full reference.

***

### 9. Use /permissions Instead of --dangerously-skip-permissions

Never use `--dangerously-skip-permissions`. Instead, use `/permissions` to pre-allow common bash commands that you know are safe in your environment. This avoids unnecessary permission prompts without sacrificing safety.

Most of these are checked into `.claude/settings.json` and shared with the team. Example allowed commands:

* `Bash(bq query:*)`
* `Bash(bun run build:*)`
* `Bash(bun run lint:file:*)`
* `Bash(bun run test:*)`
* `Bash(bun run typecheck:*)`
* `Bash(cc:*)`
* `Bash(find:*)`

{% hint style="info" %} Be explicit about what is safe rather than turning off all safety checks. {% endhint %}

***

### 10. Connect Claude Code to Your Tools via MCP

Claude Code can use all your tools. It can search and post to Slack (via the MCP server), run BigQuery queries to answer analytics questions (using `bq` CLI), grab error logs from Sentry, and more.

The Slack MCP configuration is checked into your `.mcp.json` and shared with the team:

```json
{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://slack.mcp.anthropic.com/mcp"
    }
  }
}
```

The more tools Claude can access, the more autonomously it can work. Give it access to your observability stack, your project management tools, and your communication channels.

***

### 11. Use /loop and /schedule for Automated Work

Two of the most powerful features in Claude Code are `/loop` and `/schedule`. Use these to have Claude run automatically at a set interval, for up to a week at a time.

Example loops running locally:

* `/loop 5m /babysit` to auto-address code review feedback, auto-rebase, and keep PRs moving
* `/loop` combined with a slash command to periodically check build status or run regression tests

`/schedule` lets you set up one-off or recurring runs at specific times rather than intervals. Both are useful for the kind of background maintenance work that otherwise interrupts your focus.

For very long-running tasks, you can also use these strategies:

* Prompt Claude to verify its work with a background agent when it finishes
* Use a Stop hook to perform verification more deterministically
* Use the ralph-wiggum plugin (a community plugin originally by @GeoffreyHuntley) for managing long-running sessions

Long-running sessions can consume millions of tokens (2.4M+ in some cases) and run for over a day, so having a strategy for verification and recovery is essential. See [code.claude.com/docs/en/schedule](https://code.claude.com/docs/en/schedule) for the full reference.

***

### 12. Give Claude a Feedback Loop

This is probably the most important tip: give Claude a way to verify its work. If Claude has a feedback loop, it will 2 to 3x the quality of the final result.

Claude should test every single change before it lands. This means running typechecks after code changes, running the relevant test suite, linting modified files, and verifying the build still passes.

The combination of a good `CLAUDE.md` (telling Claude how to verify) and pre-allowed permissions (letting Claude verify without interruption) is what makes this feedback loop tight and effective.

#### The Chrome Extension for Frontend Work

For web development, the feedback loop principle extends to the browser. Install the Claude Code Chrome extension (available for Chrome and Edge) to give Claude the ability to see and interact with your running application. Think of it like any other engineer: if you ask someone to build a website but they are not allowed to use a browser, the result probably will not look good. Give them a browser and they will write code and iterate until it does.

The Chrome extension tends to work more reliably than other similar MCP-based browser tools. Use it every time you work on web code. Download the extension at [code.claude.com/docs/en/chrome](https://code.claude.com/docs/en/chrome).

***

### 13. IDE Integration: VS Code as a Worked Example

Everything in the sections above works identically in VS Code (and its forks Cursor and Windsurf). Install the official "Claude Code" extension from the marketplace, and you get a sidebar chat panel backed by the same engine as the CLI. The IDE adds several features worth using deliberately.

#### Richer Plan Mode

In the terminal, Plan mode is a text exchange. In VS Code, Claude's plan opens as a full editable markdown document. You can leave inline comments directly on the plan, and Claude will read and incorporate them before it starts writing code. You are not just approving a plan, you are annotating it.

#### Automatic Context Sharing

The extension automatically shares your currently open file, highlighted selection, and the contents of the Problems panel (lint errors, type errors, diagnostics) with Claude. You can highlight a broken function and type "fix this" without any copy-pasting. In the terminal, you would need to describe the context or use `@` references manually.

#### @-Mentions for Files, Selections, and Terminals

You can reference specific files with `@filename.ts`, include line ranges from your current selection, or pull in terminal output using `@terminal:name` (where "name" is the terminal's tab title). This is especially useful for feeding test failures or build logs into Claude without leaving your editor.

#### Native Inline Diffs

When Claude proposes changes, VS Code shows them in its native diff viewer with accept/reject controls per hunk. This is a significant improvement over the terminal's ANSI-coloured text diffs, especially for large multi-file changes where you want to review carefully.

#### Multiple Conversation Tabs

You can open multiple Claude conversations in separate tabs or windows within VS Code, each scoped to a different task. Combined with the parallel sessions pattern from Section 1, this gives you a visual workspace where each tab is a distinct workstream.

#### Permission Mode Defaults

Set your preferred starting mode in VS Code settings under `claudeCode.initialPermissionMode`. If your team's convention is to always start in Plan mode, you can enforce that as the default so nobody accidentally starts in auto-accept.

#### What the IDE Does Not Replace

A few CLI features do not have full equivalents in the extension yet. Checkpoint management and extended autonomous operation (the kind of multi-hour, multi-million-token sessions described in Section 11) are better suited to the terminal. Background task visibility is also more limited in the extension. For long-running agentic work, the terminal remains the stronger option, and you can always resume that session in VS Code later with `claude --resume`.

***

### 14. The Desktop App and Cowork Dispatch

The Claude Desktop app bundles in the ability for Claude to automatically run your web server and test it in a built-in browser. This makes the feedback loop from Section 12 even tighter for frontend work: Claude writes the code, starts the server, checks the result visually, and iterates, all without you configuring anything. You can set up something similar in the CLI or VS Code using the Chrome extension, but the Desktop app handles it out of the box. See [code.claude.com/docs/en/desktop](https://code.claude.com/docs/en/desktop) for details.

#### Cowork Dispatch

Dispatch is a secure remote control for the Claude Desktop app. It lets you catch up on Slack and emails, manage files, and run tasks on your laptop from your phone, even when you are not at your computer. When you are not coding, you are dispatching.

Dispatch can use your MCPs, browser, and computer, with your permission. It is especially useful for the kind of non-coding work (triaging messages, moving files, checking dashboards) that otherwise pulls you back to your desk.

***

### 15. Use Git Worktrees for Serious Parallel Work

Claude Code ships with deep support for git worktrees. Worktrees are essential for doing lots of parallel work in the same repository. Use `claude -w` to start a new session in a worktree, or check the "worktree" checkbox in the Claude Desktop app.

For non-git version control systems, use the `WorktreeCreate` hook to add your own logic for worktree creation.

#### /batch for Massive Changesets

`/batch` takes parallel work to the extreme. It interviews you about what needs to change, then fans out the work to as many worktree agents as it takes (dozens, hundreds, even thousands) to get it done. Use it for large code migrations and other sweeping changes that would take a human team days or weeks.

***

### 16. Fork Your Session

People often ask how to fork an existing session so they can explore a different direction without losing their current context. Two ways:

1. Run `/branch` from within your session. Claude creates a branched conversation and tells you how to resume the original.
2. From the CLI, run `claude --resume <session-id> --fork-session`.

This is useful when you want to try an alternative approach to a problem without committing to it, or when a session has built up valuable context that you want to preserve while experimenting.

***

### 17. Use /btw for Side Queries

`/btw` lets you ask quick questions while the agent continues working. It opens a lightweight overlay that does not interrupt Claude's current task.

For example, while Claude is in the middle of a large refactor, you can type `/btw how do I spell dachshund?` and get an instant answer without breaking Claude's flow.

***

### 18. Use --add-dir for Multi-Repo Work

When working across multiple repositories, start Claude in one repo and use `--add-dir` (or `/add-dir` during a session) to give Claude access to the other repo. This not only tells Claude about the second repo but also gives it permissions to read and write there.

For a permanent setup, add `"additionalDirectories"` to your team's `settings.json` so the extra paths are always loaded.

***

### 19. Use --bare for Fast Non-Interactive Startup

By default, when you run `claude -p` (or use the TypeScript or Python SDKs), Claude searches for local `CLAUDE.md` files, settings, and MCPs. For non-interactive usage like scripting or CI pipelines, this overhead is unnecessary and can slow startup by up to 10x.

Use the `--bare` flag to skip all of that. With `--bare`, you explicitly specify what to load, keeping startup fast and predictable.

```bash
claude -p "summarize this codebase" \
  --output-format=stream-json \
  --verbose \
  --bare
```

***

### 20. Use /voice for Voice Input

You can do most of your coding by speaking to Claude rather than typing. Run `/voice` in the CLI, then hold the space bar to speak. On the Desktop app, press the voice button. On iOS, enable dictation in your settings.

Voice input is especially useful for plan-mode conversations where you are describing intent and architecture rather than writing precise code. It is faster than typing for exploratory work.

***

### Quick Reference: File and Config Locations

| File                    | Purpose                                                            |
| ----------------------- | ------------------------------------------------------------------ |
| `CLAUDE.md`             | Project instructions, team conventions, and learned mistakes       |
| `.claude/commands/`     | Slash commands for repeated workflows                              |
| `.claude/agents/`       | Agent definitions with custom system prompts and tool restrictions |
| `.claude/settings.json` | Allowed permissions, preferences, and additional directories       |
| `.mcp.json`             | MCP server configurations (Slack, etc.)                            |

***

### Quick Reference: Useful Slash Commands

| Command           | What it does                                              |
| ----------------- | --------------------------------------------------------- |
| `/branch`         | Fork the current session into a new branch                |
| `/btw`            | Ask a side question without interrupting the current task |
| `/loop`           | Run a prompt repeatedly at a set interval                 |
| `/schedule`       | Schedule a prompt to run at a specific time               |
| `/batch`          | Fan out a changeset across many worktree agents           |
| `/voice`          | Enable voice input                                        |
| `/teleport`       | Continue a cloud session locally                          |
| `/remote-control` | Control this session from another device                  |
| `/permissions`    | Manage allowed commands                                   |
| `/ide`            | Connect to your IDE from an external terminal             |

***

### The Philosophy in Summary

The throughline across all of these patterns is the same: invest upfront in Claude's environment and instructions so that it can work more autonomously, verify its own work, and compound its knowledge over time. Plan before you execute. Encode your learnings. Give Claude the tools and permissions it needs. And always, always give it a way to check its own work.

***

*This resource is maintained by* [*AI For Global Education*](https://aiforglobaleducation.org/) *(UK Charity No. 1213764). AIFGE supports responsible AI adoption in education through open resources, tooling, and community engagement. For more on our work, visit* [*aiforglobaleducation.org*](https://aiforglobaleducation.org/)*.*