The non-obvious tricks.

Parallel worktree sessions.

The single biggest productivity multiplier in Claude Code: stop running one session at a time. Run 3–5 in parallel, each in its own git worktree, each working a different ticket. The CLI has native support. Almost no one uses it.

Copy# Start an isolated session in a new worktree
claude --worktree
claude --worktree my-feature       # named

# Open it in a new terminal window
claude --worktree my-feature --tmux

The discipline

• Name your worktrees. auth-rewrite, not tmp-3.
• Color-code terminal tabs so you don’t lose track.
• Enable terminal notifications. You’ll get a ping when a session is waiting on you.
• Set shell aliases. alias auth='cd ~/wt/auth-rewrite && claude'.

The first prompt in each worktree

Drop this in the moment you start a fresh session in a new worktree. It primes Claude with what's different about this worktree vs the others you have running.

Copy# Paste this as your first message in a new worktree's Claude session
You're in a git worktree on branch `feat-x` (replace with the actual
branch name), isolated from main. This worktree has one job: [one sentence
describing the feature].

Other Claude sessions are working the other worktrees at the same time, so
stay inside this feature's blast radius. If the work needs a file outside
it, ask me before you edit that file.

Show me your plan and get my OK before you change code.

Why this works: The "other Claude sessions are working the other worktrees" line dramatically reduces a known failure mode. Parallel sessions reaching into each other's files. Claude respects an explicit blast-radius rule far better than an implicit one. Notice what the prompt doesn’t say: which files to skim, how many bullets the plan gets, which git command to run first. It gives the goal, the constraint, and the reason; Claude works out the investigation itself.

Plan mode & auto-accept.

Press Shift+Tab until the status bar shows ⏸ plan mode on (or prefix one prompt with /plan) when the approach is uncertain, the change spans files, or the code is unfamiliar. Refine the plan in dialogue; then let it run. If you could describe the diff in one sentence, skip the plan.

The combination matters. Approving every edit one by one after you’ve already agreed the plan is slow. Running hands-off without a plan on a change you haven’t scoped makes Claude move fast in the wrong direction (expensive). Plan first, then approve the plan into Auto or Accept-edits mode, and ship fast in the right direction.

The plan-mode prompt that compresses 30 minutes into 8

Plan mode already investigates on its own. What it can’t guess is what you need to see before you say yes. Tell it what the plan has to contain, not how to research it.

Copy# Use this BEFORE switching out of plan mode
I want to [one sentence describing the change].

Before I approve, the plan needs:
- The changes file by file, a line or two each.
- Where this could break something else.
- Which tests change, and why.
- Your confidence (1-5) that this is the right approach. If it's below 4,
  say what would raise it.

I'll read it before approving, so make it easy to scan.

The confidence score is the trick. Without it, plan mode turns into "do you approve?". Which you'll just answer yes to. The score forces Claude to flag its own uncertainty, which is the signal you actually wanted.

The model + effort combo for plans

Start with the default, Opus 5.5 at medium effort, for both plan and build. Judge it by cost per finished change, not price per token. A plan that keeps coming back wrong is the signal to raise effort (/effort high) for the planning turn, not to add longer instructions. If you want cheaper execution, the opusplan model alias plans with Opus and builds with Sonnet. Measure it on your own changes before you make it the default (as of Oct 2026).

Effort & fast mode.

Two knobs that change how Claude trades quality for speed. The defaults that experienced operators converge on after a few weeks of using the tool seriously.

Level guidance follows the model configuration docs (as of Oct 2026). Effort is the depth control; “think harder” in a prompt is just text. Claude Code recognizes only ultrathink, for one deeper turn.

Subagent isolation.

Add isolation: worktree to an agent’s frontmatter and the harness will dispatch it in a fresh worktree. Parallel investigation without polluting the main context.

Copy---
name: dependency-auditor
description: Audits package.json for outdated and abandoned deps. Run proactively before any release.
tools: [Bash, Read, WebFetch]
isolation: worktree
---

Your job is to audit dependencies...

Combined with the /batch command from the support article: “Use /batch to fan work across dozens of worktree agents automatically.” Twenty migrations in parallel; the main session only sees the summaries.

Hooks at scale.

Hooks aren’t one-off scripts. They’re your team’s conventions, enforced by the harness so Claude can't forget them. The five patterns that pay off fastest:

The Stop hook is especially powerful. Have the harness run a deterministic check (tests pass? lint clean?) before claiming the work is finished. If the check fails, the harness re-prompts Claude with the failure. This is how you get an agent that actually hits its goals.

The starter settings.json. Five hooks, paste-ready

This is the walk-away config the practice promises: five hook events wired at once, each on a different event from the table above. Save it to .claude/settings.json (project-local) and every session in this repo runs all five. The commands are deliberately conservative. Format-if-present, warn-don’t-block on destructive Bash. So you can paste first and tighten later.

Copy{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "in=$(cat); echo \"$in\" | grep -Eq \"rm -rf|git push --force|git reset --hard|: >\" && { echo 'Blocked: destructive command.' >&2; exit 2; }; exit 0"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx --no-install prettier --write . 2>/dev/null || true" }
        ]
      }
    ],
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "echo \"Branch: $(git branch --show-current). Last 5 commits:\"; git log --oneline -5" }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "npm test --silent 2>/dev/null || echo 'Tests not green — verify before done.'" }
        ]
      }
    ],
    "PreCompact": [
      {
        "hooks": [
          { "type": "command", "command": "date +'## context compacted %Y-%m-%d %H:%M' >> .claude/compaction.log" }
        ]
      }
    ]
  }
}

Voice input.

From the support article: “/voice or microphone button for space-bar recording; ~3× faster than typing.”

Use cases that earn the trade-off:

• Describing a feature you want at the start of a session (the description is always longer when you talk than when you type).
• Reading aloud a stack trace or error so Claude has full context.
• Quick “run the tests, deploy if green” style commands during a walk.

MCP from a CLI.

MCP servers are usually associated with Claude Desktop. They work just as well in Claude Code. Two patterns the support article highlights.

Data analytics

Wire bq (BigQuery CLI) or your warehouse’s MCP server. Ask Claude to pull metrics, plot them, summarize. You never write SQL; Claude does. The MCP server enforces the safe-query patterns.

Bug fixing from Slack

Connect a Slack MCP server. Paste a bug-report thread URL. Say “fix.” Claude reads the thread, finds the relevant code, proposes the fix, opens a PR. Zero context-switching between Slack and the editor.

Log troubleshooting

Point Claude at docker logs for a distributed system. The model can scan thousands of lines for patterns a human would miss. Useful for the “something’s slow but I don’t know what” class of problem.

Sandboxing & permissions.

As your agent does more, the cost of one wrong action grows. Three primitives from the support article keep that cost bounded.

Copy# Pre-approve known-safe commands so you stop confirming each one
/permissions
> add Bash(bun run *)
> add Edit(/docs/**)

# Run a session in a sandbox (file/network isolation)
/sandbox            # toggle sandbox mode on/off (file/network isolation)

# Auto mode: a classifier reviews each action and blocks what looks risky
claude --permission-mode auto

Remote & mobile.

Claude Code escaped your laptop. Remote Control, the mobile app, push notifications, and channel plugins make sessions portable.

• Mobile app. Open the Claude iOS/Android app, switch to the Code tab, and connect to a Remote Control session running on your machine.
• Remote Control. /remote-control or claude --remote-control enables phone or web control of your local session. Watch what Claude is doing from the next room.
• Push notifications. Enable push in /config so long-running work can notify your phone when tests finish or Claude needs a decision.
• Channels. Install a channel plugin or build your own when you want external events from Telegram, Discord, CI, or team chat to trigger local Claude Code work.

Scheduled local loops.

Claude Code can babysit a long-running task without you. Two flavors.

Copy# A local loop on a recurring interval (laptop must stay awake)
/loop 5m /babysit-prs        # every 5 minutes, run /babysit-prs

# A cloud job (laptop can sleep; runs in the cloud)
/schedule '0 6 * * *' /morning-brief

The cloud-job version is what makes the morning briefing in NanoClaw / Real-Life Claude feasible without owning hardware. The loop runs in the cloud; you get the output on your phone.

Multi-repo workflows.

Most engineers work across more than one repo. Claude Code has CLI flags and slash commands that grant cross-repo access cleanly.

Copy# Grant access to additional directories
claude --add-dir ~/other-repo
# or inside a session:
/add-dir ~/other-repo

# Bare mode for fast SDK startup (skips local discovery)
claude -p 'task description' --bare

# Branch a session — useful for exploring two paths from the same plan
/branch
# or from outside the session:
claude --resume <session-id> --fork-session

Treat Claude Code like a package manager.

Motto: the most under-used productivity move is installing a plugin that already solves your problem.

Skills are single-purpose. Plugins are multi-tool bundles. A packaged set of commands, sub-agents, hooks, and tools that turn Claude Code into a specialised version of itself for one workflow. Three things to know:

1. Install in seconds. /plugin install <plugin>@<marketplace> in any Claude Code session pulls a plugin from a marketplace and wires it in.
2. One plugin can replace a week of homemade scripts. Codebase-onboarding, deployment workflows, doc generation, testing pipelines. If someone has already published it, install rather than build.
3. Plugins are removable. If a plugin clutters your slash-command namespace or you stop using it, /plugin uninstall <plugin>@<marketplace> and it’s gone. Try with low cost.

The case-study pattern: codebase onboarding via knowledge graph

One of the most useful plugin patterns is "scan-the-repo, build a graph, give me a guided tour." A multi-agent pipeline (orchestrator + per-file workers + synthesizer) reads every file, extracts entities and relationships, and assembles a navigable map. New team member, 200k-line codebase, two hours of guided exploration instead of two months of stumbling.

You don’t need to build it; the pattern exists. The lesson is: before you write a tool, check the Discover tab and your configured marketplaces. Two minutes saves two weeks.

Copy# Browse before you build
/plugin

# List configured marketplaces
/plugin marketplace list

# Install when something fits
/plugin install <plugin-name>@<marketplace-name>

# Apply plugin changes during the current session
/reload-plugins

# Clean up what didn't stick
/plugin uninstall <plugin-name>@<marketplace-name>

The "build vs install" decision in 60 seconds

• Install if: a plugin exists that does ≥70% of what you want, AND its hooks/commands won’t clash with yours.
• Build a skill if: it’s a single repeated task, narrow, you want full control.
• Build a plugin if: it’s a bundle of related capabilities your whole team would use; publish it back if it generalizes.

The under-rated move: 90% of engineers who hit "Claude Code can’t do X" don’t check whether someone else already published a plugin that does X. The Discover tab is the cheapest first move every single time.

The awesome list.

The community has organized itself around two repos that are worth pinning. Read them periodically; the field moves fast.

• awesome-claude-code. Curated skills, hooks, slash commands, agents, plugins. 80+ specialized sub-agents in Seth Hobson’s collection.
• awesome-claude-skills. Curated SKILL.md files for every domain from quant finance to legal review.
• Dan Avila’s plugin marketplace. DevOps automation, doc generation, project management, testing suites.
• shinpr/claude-code-workflows. End-to-end development workflows with specialized agents.

The discipline: every fortnight, scan the awesome lists for one new pattern. Test it against your work. If it sticks, adopt; if not, move on. The cost of trying one new pattern is half an hour. The value of one that sticks is the rest of your year.

Your power-user CLAUDE.md.

The single highest-leverage artifact from this practice. Drop this in ~/.claude/CLAUDE.md. It loads into every Claude Code session you start, anywhere, forever.

Copy# Save to ~/.claude/CLAUDE.md — loads in every session
# CLAUDE.md — personal power-user defaults

## How I work
- I run 3-5 parallel worktrees. Before editing, check `git worktree list`
  and confirm you're not stepping on another session's blast radius.
- For changes spanning more than one file I start in plan mode. Put a
  1-5 confidence score in every plan so I know how hard to review it.
- When I name something loosely ("the auth handler"), find it and tell
  me which file you picked.

## Defaults
- Run the tests before committing. If the area you touched has no
  tests, suggest one.
- Use the `gh` CLI for GitHub operations; it's authenticated here and
  the web pages aren't.

## Hooks in my setup
- A PreToolUse hook blocks rm -rf, force-push, and reset --hard. If it
  blocks you, tell me what you were trying to do rather than working
  around it.
- A Stop hook runs the test suite. When it reports red, fix that before
  calling the work done.

## How I like replies
- Lead with the code when the answer is code. When something fails, say
  what happened and what you'll do next, then stop.
- No emoji in code comments.

## My stack defaults (override when project differs)
- Language: [your default]
- Package manager: [your default]
- Test runner: [your default]
- CI: GitHub Actions
- Cloud: [your default]

Customize the bracketed parts, drop it in ~/.claude/CLAUDE.md, and it loads automatically in every Claude Code session you start. This file alone replaces 3-5 minutes of re-explaining yourself at the start of each session. Two things it deliberately leaves out. Effort: CLAUDE.md is context, not configuration, so set it with /effort (saved per model) or effortLevel in settings. The hooks themselves: they live in settings.json (Unit 05); the section above only tells Claude what they’ll do, so it doesn’t fight them. Keep the file short. For each line, ask whether Claude would get something wrong without it; if not, cut it (as of Oct 2026).