Chapter 15: Advanced Moves

15 min read

Using Plan Mode Before Any Significant Project

This bears repeating as a dedicated section: plan mode should precede every significant project. Not just “complex” projects — any project where:

You are creating something new (a website, a report, an analysis)
Multiple approaches exist and you want the best one
The task has more than three distinct steps
You are not sure what the end product should look like

The plan mode workflow:

> [Shift+Tab twice to enter plan mode]

I need to create [describe the project]. Before we build anything:

1. Read the relevant files in this directory
2. Consider 2-3 different approaches
3. Recommend the best approach and explain why
4. Present a step-by-step plan for my review

Do not make any changes. Just present the plan.

After reviewing and approving:

> [Shift+Tab to exit plan mode]

Execute the plan we discussed. Start with step 1.

The Ralph Loop: Iterative Self-Improvement

The ralph-loop plugin enables a powerful workflow where Claude iteratively improves its own output. Instead of you providing feedback on every detail, Claude critiques its own work and makes improvements autonomously.

As a Claude prompt:

/ralph-loop

Build a hero section for a landing page about [product/service].
After each iteration, self-critique and improve the design.
Continue for 3 iterations.

Claude will: 1. Build the initial version 2. Review it critically (identifying weaknesses) 3. Improve based on its own critique 4. Repeat for the specified number of iterations

This is especially useful for design work where “make it better” is hard to specify in words but easy to recognize visually.

Using Multiple Plugins Together

The most powerful workflows combine multiple plugins. Here are patterns I use regularly:

Website project: frontend-design (build) + playwright (screenshot/verify) + commit-commands (save) = design, verify, and deploy in one session.

Research project: context7 (current docs) + web tools (research) + document-skills (create PDF deliverable) = research and produce a polished deliverable.

Content project: Web tools (gather material) + data analysis (create charts) + document-skills (format output) = data-driven content pipeline.

Advanced Workflow Patterns

Several workflow patterns push beyond basic task execution:

The “second agent review” pattern. A workflow where you use plan mode to create a plan, then spin up a second Claude session to review the plan as if it were a “staff engineer.” The second agent critiques the plan before execution, catching potential issues. For non-technical users, the equivalent is: create your plan in one session, then open a new session and paste the plan with the instruction “Review this plan and identify potential problems, missing steps, or risks.” This adds a verification layer that catches errors before they cascade.

Parallel agent delegation. Using parallel subagents for research tasks: “Spin up three user research agents, each interviewing from a different persona perspective.” Claude dispatches three simultaneous investigations and synthesizes the results. For non-technical users, this pattern is accessible through Claude Code’s Task tool — when you have three independent research questions, you can ask Claude to investigate all three in parallel.

Persistent planning files over ephemeral plan mode. A growing school of thought argues that the built-in plan mode is inferior to maintaining dedicated planning files (like PLAN.md and RESEARCH.md) in your project directory. The reasoning is sound: plan mode plans disappear after the session, but persistent files survive across sessions, can be annotated in your text editor, and serve as long-term project memory. This is exactly the approach I describe in Chapter 4’s Research-Plan-Execute framework — RESEARCH.md and PLAN.md as visible, annotatable files that become the backbone of any serious project. I use plan mode for quick session-level exploration and the full framework with persistent files for anything that spans more than one session or matters enough to get right the first time.

The GSD Workflow System

The GSD (Get Stuff Done) plugin provides a structured project management framework within Claude Code. It includes:

Phase-based planning: Break projects into numbered phases
Execution tracking: Monitor progress against the plan
Checkpoint and rollback: Save state and revert if needed
Verification loops: Confirm each phase achieved its goals before moving on

For large projects (like building a website or writing a report), the GSD framework provides the structure that keeps things on track across multiple sessions.

Rate Limit Strategies

When you work intensively, you will hit rate limits. Here is how I manage them:

Front-load complex tasks: Do your most intensive work (large file processing, multi-step workflows) at the start of a session when your rate limit is fresh.
Batch instructions: Instead of sending ten short instructions, send one comprehensive instruction. This uses one API call instead of ten.
Use plan mode for thinking: While you are rate-limited, enter plan mode for your next task. Planning uses less capacity than execution.
Switch to lighter tasks: If you hit a limit during heavy processing, switch to lighter tasks (file organization, CLAUDE.md updates, writing notes) while the limit resets.
Take breaks strategically: Rate limits reset on a rolling window. A five-minute break during a limit often costs less time than trying to push through.

Scheduled Tasks: `/loop` as an Advanced Power Tool

Chapter 11 introduced /loop for basic scheduled automation. Here is where it gets interesting for power users.

Looping over other commands and skills. The scheduled prompt can itself invoke a slash command or skill:

Inside Claude Code:

/loop 20m /review-pr 1234
/loop 1h /commit-commands:commit
/loop 30m check my email inbox for messages from [sender] and summarize any new ones

This means any skill you have built or installed becomes a recurring automated workflow with one line.

The cron reality underneath. Under the hood, /loop converts your natural language interval into a standard cron expression. If you need precise scheduling — “every weekday at 9am” or “every hour on the hour” — Claude supports that too. The scheduler runs locally in your session, checking every second for due tasks and firing them between your conversation turns at low priority.

The 3-day ceiling and what to do about it. Recurring tasks auto-expire after 3 days. This is a deliberate safety measure — forgotten loops should not run indefinitely. For longer-running automation, you have two options:

Recreate the loop. Cancel and re-issue the /loop command every few days. Simple and effective for most cases.
Use Desktop scheduled tasks. For truly persistent scheduling that survives session restarts, Claude Code Desktop offers scheduled tasks that run locally, each firing a fresh session at the configured frequency. For unattended cron-style automation beyond the CLI, consider a GitHub Actions workflow with a schedule trigger.

Disabling the scheduler. If you find scheduled tasks distracting or want to disable them in certain environments, set CLAUDE_CODE_DISABLE_CRON=1 in your environment. The cron tools and /loop become unavailable.

`/goal`: Keep Claude Working Until It Is Actually Done

/loop re-runs a prompt on a timer. /goal solves a different problem: work that should continue until a condition is true, however many turns that takes.

Inside Claude Code:

/goal every CSV in this folder has a cleaned copy in /processed and a summary row in report.md

Setting a goal starts Claude working immediately. After each turn, a separate small model — not the one doing the work — reads the conversation and decides whether your condition is met. If not, Claude keeps going without waiting for you. If yes, the goal clears itself. While it runs, a ◎ /goal active indicator sits on screen; type /goal with no argument to see turns and tokens spent so far, and /goal clear to stop early.

Two rules make goals behave. First, write a condition Claude’s own output can prove — “the script runs without errors,” “all 12 files are converted” — because the evaluator only reads the conversation; it cannot open your files itself. Second, put a ceiling in the condition, like “or stop after 15 turns,” so a badly specified goal cannot run away with your usage. Used well, this pairs naturally with the long-range project patterns from Chapter 12: set the goal, let Claude grind, come back to a finished state.

Building Project-Specific Slash Commands

When you find yourself repeating the same workflow in a project, you can create a custom slash command. This is one of the most underused power features of Claude Code.

For example, in my personal website project, I created a custom /add-post command. Every time I write a new LinkedIn post, I run this command and Claude automatically: 1. Extracts the post metadata (title, date, tags) 2. Creates the right file in the correct directory with proper naming 3. Formats it for the website’s CMS system 4. Assigns topic tags based on the content

What used to be a 5-minute manual process became a 10-second command.

How to create a custom command:

Custom commands are defined in your plugin’s commands/ directory. Each command is a markdown file that describes what the command should do. You do not need to write code — you write instructions, and Claude follows them.

Your plugin directory:
.claude-plugin/
  plugin.json
  commands/
    add-post.md    ← Your custom command

The command file contains the system instructions Claude follows when the command is invoked. For example, an add-post.md might contain:

Example command file (add-post.md):

---
name: add-post
description: Add a new LinkedIn post to the personal website
---

When the user runs /add-post, do the following:
1. Ask for the LinkedIn post URL or the post content
2. Extract the title from the first line of the post
3. Generate a slug from the title
4. Create a new markdown file in /content/posts/ with the correct frontmatter
5. Assign topic tags based on the content
6. Confirm the post was added with a summary

This is one of those features that compounds over time. Each custom command you build saves you minutes per use, across hundreds of uses.

The MCP Tool Search: Lazy Loading for Efficiency

A newer feature worth knowing about: MCP Tool Search enables lazy loading for MCP servers. If you install many MCP servers, they all consume context window space (even when you are not using them). Tool Search reduces this by up to 95% — MCP tools only load into context when Claude actually needs them.

This means you can install 10+ MCP servers without worrying about context limits. Install liberally, and Tool Search handles the efficiency.

Working with Multiple Models

Claude Code supports different models, and knowing when to use which one can optimize both quality and speed. As of mid-2026, the lineup is the Claude 5 generation:

Sonnet 5 — The default on the Pro plan. A 1-million-token context window, thinking on by default, and more than capable for most workflows in this book. Everyday sessions, quick edits, high-volume work.
Opus 5 — The smartest everyday tier, and the default on Max and Team Premium. Best for complex analysis, long-form writing, and tasks requiring deep reasoning. Pro users can select it, with tighter usage limits.
Haiku — The fastest and most affordable. Best for simple operations, quick lookups, and batch processing.
Fable 5 — Anthropic’s most capable model. It ships on the API and cloud platforms, not as a subscription default, so it is relevant mainly if you pay per token (--model fable).

You can switch models mid-session with /model, or set a default in settings.json ("model": "opus" — the aliases sonnet, opus, and haiku always point at the current version of each tier). For intensive writing and analysis, Opus produces noticeably better results. For batch processing or quick operations, Sonnet or Haiku saves time and rate limit capacity.

Background Agents and Parallel Work

One of Claude Code’s most powerful advanced features is the ability to dispatch work to background agents. Instead of doing everything sequentially, you can have Claude work on multiple tasks simultaneously.

When this matters: Imagine you are preparing for a presentation. You need: - A data analysis of last quarter’s metrics - Three different slide designs for the key finding - A research summary on your industry sector

Instead of doing these one after another, you can dispatch each to a background agent. All three run in parallel, and you review the results when they complete.

As a Claude prompt (pattern):

As a Claude prompt:

I need three things done in parallel:

1. Analyze the CSV in /data/q4-metrics.csv — give me the top 5 trends
2. Research recent developments in [industry sector] — summarize the 3 biggest shifts
3. Create a one-page executive summary template in HTML

Please dispatch these as parallel tasks.

Claude will use its Task tool to launch separate agents for each item. This is particularly valuable when individual tasks take several minutes — running three 5-minute tasks sequentially takes 15 minutes, while running them in parallel takes just 5.

Agent Teams: The Frontier of Parallelization

Agent teams take the sub-agent concept to the next level. Where sub-agents are individual workers dispatched by a parent agent, agent teams are full orchestrated groups — a team lead manages multiple independent agents, each with their own context window, tools, and ability to communicate with each other.

How agent teams differ from sub-agents:

Sub-agents own their context but always report back to the parent agent. They are focused workers doing one job.
Agent team members own their own context, are fully independent, and can communicate directly with each other through a shared scratchpad — not just with the team lead. They can coordinate, share findings, and build on each other’s work.

The most compelling use case: adversarial improvement. You can spin up two “debate” agents that take opposing positions. One argues that a finding is valid; the other argues it is not. They go back and forth, challenging each other’s reasoning, until they reach consensus. The result is higher-quality analysis than either agent would produce alone. This adversarial pattern — borrowed from a concept in machine learning called generative adversarial networks — forces rigor.

A practical example: You are building a website. You ask the team lead to spin up three agents, each creating a fundamentally different design direction. All three work in parallel, accessing their own tools and taking their own screenshots. When they finish, the team lead synthesizes the results and presents you with three options. You pick a direction, and the team lead dispatches a new round of agents to iterate on it — one focused on copy, one on visual polish, one on responsiveness. Each round narrows toward a better result.

The cost reality: Agent teams are expensive. Every team member is a full Claude instance with its own context window. Ten active agents consume roughly ten times the tokens of a single agent. A complex team session can cost $50-100+ in API usage. This is a feature for specific situations — large creative explorations, deep security audits, complex research synthesis — not for everyday tasks.

Current status: Agent teams are an experimental feature, currently available only in the terminal (not IDEs or the desktop app). You enable them by setting CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in your settings. They may become more accessible and affordable over time, but for now, they represent the bleeding edge of what is possible with Claude Code.

Fair warning before this section: this is the deepest water in the book. Everything else in this chapter you could adopt this week. This exists so you know where the ceiling is — not because you need it now.

Multi-agent work in Claude Code has settled into four patterns, and it helps to see them as one menu:

Sub-agents — delegated workers inside one session (Chapter 11, and “Background Agents” above). These now run in the background by default, so Claude keeps working on your main task while they run and picks up their results when they finish.
Agent view — one screen for every Claude Code session you have going. Run claude agents in your terminal to see what is running, what is finished, and what is blocked waiting on you. Currently a research preview.
Agent teams — the previous section: coordinated workers with a shared task list, managed by a lead. Experimental, off by default.
Dynamic workflows — the heaviest machinery: for a job too big to coordinate one turn at a time, ask Claude to “create a workflow” and it writes an orchestration script that runs tens to hundreds of sub-agents and cross-checks their results against each other. Think codebase-wide audits or a 500-file migration. Type /workflows to see your runs.

My honest guidance for this book’s audience: the first pattern is the only one to use regularly, and you already know how — describe independent tasks and ask Claude to run them in parallel. When you outgrow that, claude agents is the natural next step. The rest is genuinely the deep end, and it carries the deep end’s price: every parallel worker is a full Claude session, so a big run multiplies token usage accordingly. Wade in when a real project demands it, not before.

Git Worktrees: Parallel Development Without Conflicts

Git worktrees solve a specific problem that arises when multiple agents work on the same project simultaneously: file conflicts. If two agents try to edit the same file at the same time, the results can be unpredictable.

A worktree creates an isolated copy of your project directory on a separate git branch. Each agent works in its own worktree, making changes independently. When they are done, the changes merge back to the main branch.

The mental model: Imagine you are renovating a house. Instead of having the plumber and electrician work in the same room at the same time (conflicts), you give each of them their own copy of the room to work in. When they are done, you merge their changes into the real room.

When worktrees matter:

When you dispatch multiple agents to work on different pages of a website simultaneously
When you want to try two different approaches to the same problem without one overwriting the other
When you are using agent teams on a shared codebase

The workflow:

As a Claude prompt:

Build three new pages for my website in parallel using git
worktrees:
1. An about page (work in its own branch)
2. A contact page (work in its own branch)
3. A services page (work in its own branch)

Each should work independently without modifying the existing
homepage. Merge all three back to the main branch when complete.

Claude creates separate worktree directories (project-about/, project-contact/, project-services/), dispatches agents to each, and merges the results when they complete.

For most users of this playbook, worktrees are a “good to know” feature rather than a daily workflow. But when you start working with multiple agents in parallel on the same project, they become the mechanism that keeps everything clean.

Computer Use: Claude at Your Screen (Research Preview)

This is the most experimental feature in the book, and I am including it with a plain warning label: it is a research preview, it changes often, and you should watch it work rather than leave it alone with your machine.

Computer use lets Claude control your actual screen — open apps, click buttons, type into fields, and take screenshots to see the result. It is how Claude reaches the things that have no file or command behind them: a native app, a settings panel, a tool that only exists as buttons on a screen. Claude treats it as the last resort, in the right order — if an MCP server, a terminal command, or the Chrome extension can do the job, it uses those first.

It ships as a built-in MCP server called computer-use, switched off by default. To try it (macOS only in the terminal, and it requires a Pro or Max plan — it is not offered on Team or Enterprise):

Inside Claude Code:

/mcp

Find computer-use in the server list and enable it. The first time Claude acts, macOS asks you to grant two permissions: Accessibility (so Claude can click and type) and Screen Recording (so Claude can see the screen).

The guardrails are real. Claude asks per app, per session, before touching anything; apps that grant broad power (Finder, terminals, System Settings) carry an extra warning; other windows are hidden while it works; and pressing Esc aborts instantly from anywhere. Even so, treat this as the frontier: genuinely useful for “click through this and tell me if it works” tasks, genuinely not ready to be your unattended assistant. The desktop app has the same capability — there it also works on Windows — with a settings toggle instead of the /mcp menu.

The Claude Code + Claude.ai Boundary

An important advanced concept: knowing when to use Claude Code versus Claude.ai (the web interface).

Use Claude Code when: - You need file system access (reading, writing, creating) - You need to run commands (media processing, data analysis, git) - You need browser automation (screenshots, scraping, testing) - You are working on a multi-session project with CLAUDE.md - You need to chain multiple tools together - You need to produce file outputs (PDFs, images, websites)

Use Claude.ai when: - You are having a conversation or brainstorming (no file operations needed) - You need to process a single document quickly with drag-and-drop - You want visual artifacts inline in the conversation - You are on a mobile device - You need the Projects feature for organized long-term conversations

The tools complement each other. Many power users keep both open — Claude.ai for conversation and quick analysis, Claude Code for execution and file-based work.