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 are working in a git worktree isolated from main. The branch is `feat-x`
(replace with actual branch name). This worktree's job is ONLY: [one sentence
describing the feature].

Before touching any code:
1. Run `git log --oneline -10` and tell me where this branch diverged from main.
2. Skim the 3 files most likely to change for this feature.
3. State the plan in 5 bullets max. Get my OK before you start.

If you find yourself about to edit a file outside the feature's blast radius,
stop and ask. We have other Claude sessions running on the other worktrees;
don't step on them.

Why this works: The "we have other sessions running" 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.

Plan mode & auto-accept.

Press Shift+Tab to enter plan mode before any non-trivial change. Refine the plan in dialogue; then switch to auto-accept.

The combination matters. Plan mode without auto-accept makes you confirm every edit (slow). Auto-accept without plan mode makes Claude move fast in the wrong direction (expensive). Plan first, accept second, ship fast in the right direction.

The plan-mode prompt that compresses 30 minutes into 8

Don't let plan mode degenerate into "think out loud." Give it shape. This is the prompt that gets a sharp, executable plan instead of a rambling outline.

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

Before any code:
1. Read the 3-5 files most affected. Tell me their current responsibility.
2. List the EXACT changes you'd make, file by file, in 1-2 lines each.
3. Identify the 1-2 places where this could break something else.
4. Tell me what tests should change and why.
5. Give me a confidence score 1-5 that this is the right approach.

If your confidence is < 4, tell me why and what would raise it.
If your confidence is ≥ 4, ask permission to switch out of plan mode.

Format the plan so I can scan it in 60 seconds.

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

Use the strongest model with high effort for the plan; switch to a faster cheaper model for the execution. One careful, expensive plan; many cheap, fast follow-throughs.

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.

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            # interactive: pick one of 3 configs

# Auto mode: harness auto-approves anything in the permission set
claude --enable-auto-mode

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 NanoClaude / 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.
- I use plan mode by default for any change spanning more than one file.
  Don't switch out of plan mode without giving me a 1-5 confidence score
  on the plan.
- I prefer explicit file paths over inferred ones. When I say "the auth
  handler", ask which file.

## Defaults
- Effort: high for plans, medium for execution.
- Always run tests before committing. If tests don't exist for the area
  you touched, suggest one.
- Use `gh` CLI for any GitHub operation. Never open the web UI.

## Hooks I rely on
- Pre-edit: linter must pass on the file before modification
- Pre-commit: prettier + eslint must pass on staged files
- Post-tool-use: log the file paths Claude touched to ~/.claude-edits.log
- Pre-bash: warn me before any rm, drop, or destructive command
- Post-task: append a one-line summary to ~/.claude-changelog.md

## Things I don't want
- Apologies. Just say what happened and what you'll do next.
- "Let me know if you need anything else" at the end of every reply.
- Emoji in code comments.
- Filler before a code block — just show the code.

## 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.