Power Tips & Best Practices

Everything in this course collapses into one principle: make Claude's agentic loop self-correcting, then bound its blast radius. Claude works in three blended phases — gather context, take action, verify results — and a power user spends their effort shaping the inputs to that loop rather than reacting to its outputs.

There are six habits that separate frustration from force-multiplication. Each one targets a specific way the loop goes wrong:

The rest of the lesson is one section per habit, with the exact commands, flags, and shortcuts. Read it fast the first time; re-read it monthly and you'll notice your own anti-patterns sharpening into reflexes.

Claude stops when work "looks done." Without a check it can run, that judgment is a vibe — so you discover the bug, paste it back, and become the verification loop by hand. The fix is to hand Claude something it can check its own work against: a test command, a build, a screenshot, a diff. Then its verify phase has teeth — it runs the check, sees red, and iterates to green before returning to you.

Say the check out loud in the prompt. "Add email validation" guesses; "Add email validation and make npm test -- signup pass, keep going until green" loops.

Plan mode is the verifier's partner for uncertainty. When a task spans multiple files, touches unfamiliar code, or you're not sure of the approach, enter plan mode (Shift+Tab to cycle to it, or --permission-mode plan, or /plan). It's read-only — Claude explores and proposes a plan with no edits, and you press Ctrl+G to edit the plan before approving. This separates research from execution so you catch a wrong approach before code is written.

Skip plan mode for small, clear fixes — typos, a log line, a rename. The overhead isn't worth it when the change is obvious. The 4-phase workflow Explore → Plan → Implement → Commit is the full version of this habit: explore in plan mode, let Claude draft the plan, exit plan mode to implement with a verifier, then commit.

The context window is 200K tokens (some models/configurations offer larger windows — run /context to see your actual budget), but performance is about quality, not size — it degrades as the window fills with raw logs, repeated reads, and forgotten history that all compete for attention. Not all of that nominal window is usable in practice either: Claude reserves a working buffer, so the practical ceiling is lower than the headline number — which is exactly why compacting at ~60% (rather than waiting for the limit) is aggressive but safe, not arbitrary. A power user manages context as aggressively as they manage code.

Use /context [all] to see the breakdown (system prompt, tools, CLAUDE.md, skills, MCP, conversation) and /usage for cost plus a per-skill/subagent/plugin/MCP breakdown. The rule of thumb: /clear between tasks, /compact at 60%, subagents for exploration.

One sharp gotcha lives here too: pasted images and screenshots are stored at full resolution in the session transcript, and accumulation can cause permanent 400 errors on resume. /clear or /compact a session that has piled up visual artifacts — we return to this under quality-at-scale.

CLAUDE.md is delivered as context (a user message), not a system prompt — so compliance is advisory, not guaranteed. Specific instructions like "use 2-space indentation" work; vague ones like "format nicely" fail. Two consequences follow directly.

Keep it under 200 lines, concrete, and project-specific. Bloat is actively harmful: Claude ignores rules lost in the noise. The test for every line is "would Claude make a mistake without this?" If Claude already does the right thing by default, delete the rule — it's costing tokens and diluting the rules that matter.

For anything that must be guaranteed, use a hook — not prose. Hooks are shell commands wired to lifecycle points (PreToolUse, PostToolUse, Stop, SessionStart, and more) in .claude/settings.json. They run on the harness, deterministically, regardless of Claude's discretion. "Always lint on save" or "block edits to this path" belong in a hook; only advice belongs in CLAUDE.md.

Use /init to generate a starter CLAUDE.md (it scans the codebase for build/test commands and conventions), /memory to see every loaded instruction file, and split topic rules into .claude/rules/ — with paths frontmatter so a rule loads only when Claude reads matching files, saving context.

When Claude heads in the wrong direction, the beginner reflex is to kill the session and start over, throwing away every good step. The power move is conversational steering: press Esc to interrupt immediately (work done so far is preserved), then type a correction. Claude reads it and adjusts after the current action — you keep the context and the progress, and only redirect the part that went wrong.

[Claude is editing the wrong module]
Esc
> Stop — that logic belongs in services/auth.ts, not in the route handler. Move it there.

You rarely need to restart. If you've corrected the same thing three times, that's the signal to /clear and re-prompt with one better instruction — repeated corrections are a prompt problem, not a steering problem.

The same "extend, don't replace" instinct applies to the system prompt. When you customize Claude's behavior in headless or SDK runs, use --append-system-prompt, never --system-prompt:

Replacing the system prompt strips the guidance that makes Claude good at using its tools. Append your project context on top of that foundation; don't bulldoze it.

Headless and unattended runs (claude -p, background agents, CI) trade supervision for scale — which means you must replace your judgment with explicit limits before the run starts. Three flags bound every dimension of risk:

claude -p "refactor the validation helper" \
  --allowedTools "Edit,Bash(npm test*)" \
  --max-turns 10 \
  --max-budget-usd 5.00

That run can edit files and run the test command, will stop after ten turns, and halts the moment spend hits five dollars. The blast radius is fully defined in advance.

For hard guarantees, use deny permission rules — not conversation. A boundary you state in chat ("don't push to main") can be dropped by compaction; a deny rule in .claude/settings.json (or via /permissions) is enforced by the harness on every tool call, no matter what the conversation says. This is the single most important safety distinction: conversation is advisory; deny rules and hooks are guaranteed.

{
  "permissions": {
    "deny": ["Bash(git push:*)", "Bash(rm -rf:*)"]
  }
}

For CI, pair these with --permission-mode dontAsk (auto-deny anything not in an allow rule) so the run never hangs on a prompt.

Once you trust the loop, you scale it — running several streams of work and reviewing them independently. Four patterns carry the load.

Git worktrees for parallel work. claude -w feature-auth opens an isolated git worktree at <repo>/.claude/worktrees/<name> so multiple sessions work on separate branches with no edit collisions. Add --tmux for visual management. Each worktree is its own clean workspace; commits remain visible across them because they share the git repo.

Writer/Reviewer. Session A writes the change; Session B reviews it in a fresh context with no memory of how the code was built — so it judges the code, not the author's intent. The fresh context is the value: bias-free eyes catch what the writing session rationalized away.

Adversarial subagent review. Spawn a subagent whose job is to attack the change — find the failure modes, the missing edge cases, the security holes. Because subagents run in isolated context and report a summary back, you get a hostile second opinion without polluting the main thread. Run /code-review or /security-review over the diff for the same effect on demand.

Manage screenshots to avoid 400 errors. This is the trap that bites long-running visual sessions: images are stored at full resolution in the session transcript, accumulation can cause permanent 400 errors on resume, and Chrome MCP screenshots cause extreme token drain. /clear or /compact a session once visual artifacts pile up — don't try to resume a session that's already broken.

Finally, /fewer-permission-prompts scans your transcripts and adds a safe, read-only allowlist to project settings — so the prompts you keep approving stop interrupting you, without weakening the rules that matter.