Go from casual prompting to a fast, repeatable workflow
Being a Claude Code power user comes down to a handful of habits and features. Here's what actually matters, roughly in order of impact:
Claude stops when the work looks done. Without a check it can run, you become the verification loop and every mistake waits for you to notice it. Give Claude something that produces a pass or fail and the loop closes on its own.
Concrete ways to do this: put test cases directly in the prompt ("write a validateEmail function; user@example.com is true, user@.com is false; run the tests after implementing"); for UI work, paste a design screenshot and tell Claude to screenshot the result, compare, list the differences, and fix them; for build failures, paste the exact error and say "fix it and verify the build succeeds, address the root cause, don't suppress the error."
To make the check binding: set it as a /goal condition so an evaluator re-checks after every turn, or wire it as a Stop hook that blocks the turn from ending until the check passes (Claude Code overrides the hook after 8 consecutive blocks, so it's a strong gate, not an infinite one). For a second opinion, have a verification subagent try to refute the result so the agent doing the work isn't the one grading it.
And always demand evidence over assertions, the test output, the command and what it returned, a screenshot, because reviewing evidence is faster than re-running the verification yourself.
Most best practices flow from one constraint: the context window holds every message, file read, and command output, it fills fast, and performance degrades as it fills.
Practical moves: use /clear between unrelated tasks; use /compact <instructions> (e.g., "focus on the API changes") when you want to shrink history but keep the thread; use /btw for side questions, the answer appears in an overlay and never enters conversation history; and after two failed corrections on the same issue, stop correcting, /clear and restart with a sharper prompt that folds in what you learned. A clean session with a better prompt almost always beats a long session full of failed attempts.
Claude can't read your mind. "Add tests for foo.py" becomes "write a test for foo.py covering the case where the user is logged out; avoid mocks." "Fix the login bug" becomes "users report login fails after session timeout; check the auth flow in src/auth/, especially token refresh; write a failing test that reproduces it, then fix it."
Reference files with @, paste screenshots, give URLs, pipe data in with cat error.log | claude -p "What caused this error and how should I fix it?", and point Claude at existing patterns in your codebase to follow.
Saying "use subagents to investigate X" runs the exploration in a separate context window and reports back a summary, keeping your main conversation clean for implementation. You can also define custom subagents as markdown files in .claude/agents/, for example a security-reviewer that runs on Opus with a restricted tool set.
And use subagents for adversarial review: have one review the diff in a fresh context against your plan, reporting gaps rather than style preferences. The bundled /code-review skill does exactly this for correctness. One caveat from the official docs: a reviewer prompted to find gaps will usually report some even when the work is sound, so tell it to flag only what affects correctness or requirements.
CLAUDE.md is loaded at the start of every session, and it's hierarchical: ~/.claude/CLAUDE.md applies to all your sessions (user memory), ./CLAUDE.md at the project root gets checked into git for the team (project memory), ./CLAUDE.local.md is your personal gitignored notes, and parent/child directory files get pulled in for monorepos.
Run /init to generate a starter file from your codebase, use @path/to/file imports to pull in other docs, and run /memory to see and edit everything that's loaded. Keep it ruthlessly short, for each line ask "would removing this cause Claude to make mistakes?", because bloated CLAUDE.md files cause Claude to ignore your actual instructions.
Separately, there's auto memory: Claude writes notes to itself as it works (build commands, debugging insights, architecture notes, your preferences) into ~/.claude/projects/<project>/memory/MEMORY.md plus topic files. It's on by default; toggle it in /memory, and just tell Claude "remember: always use pnpm" or "forget the rule about X" to manage it conversationally.
Rule of thumb: authoritative team rules go in CLAUDE.md, learned patterns go to auto memory.
The most expensive mistake is letting Claude start coding before you've agreed on what to build. The official workflow: enter plan mode and have Claude read the relevant code, ask it to produce a detailed plan (press Ctrl+G to edit the plan directly in your editor), then switch out of plan mode to implement against the plan, then commit and open a PR. Skip planning for anything you could describe as a one-sentence diff.
For big or fuzzy features, flip the script entirely: "I want to build [X]. Interview me in detail using the AskUserQuestion tool... then write a complete spec to SPEC.md", then start a fresh session to execute the spec with clean context.
Every prompt creates a checkpoint. Hit Esc to stop Claude mid-action (context preserved), Esc Esc or /rewind to restore conversation, code, or both to any previous point. Checkpoints persist across sessions, so you can tell Claude to try something risky, and if it doesn't work, rewind and try another approach. (Checkpoints only track Claude's changes, this isn't a git replacement.)
/branch is the sibling move: it copies your conversation at the current point, so you can try a risky refactor in the branch while the original path stays alive, unlike rewind, both paths survive. Name long-running sessions with /rename and resume them with claude --continue or claude --resume.
Claude Code scales horizontally, and there's a spectrum of coordination: git worktrees run separate CLI sessions in isolated checkouts so edits don't collide, extremely useful for implementing two independent features at once, comparing two possible solutions to the same problem, having one agent code while another reviews, or fixing multiple unrelated bugs in parallel.
The desktop app manages parallel local sessions visually, each in its own worktree; Claude Code on the web runs sessions in isolated cloud VMs; and agent teams add automated coordination, multiple sessions with shared tasks, messaging, and a team lead.
Parallel sessions also unlock quality workflows: the Writer/Reviewer pattern (one session implements, a second session with fresh context reviews, it won't be biased toward code it just wrote), or having one Claude write tests and another write code to pass them. For bulk work like migrations, fan out: generate a file list, then loop claude -p "Migrate $file..." --allowedTools "Edit,Bash(git commit *)" across it, testing on 2-3 files before running at scale.
Use /model to switch between Fable, Opus, Sonnet, and Haiku mid-session, and set models per subagent (e.g., an Opus-powered security reviewer, a Haiku-powered quick-search agent). The common pattern: heavier models for planning and gnarly debugging, lighter ones for well-scoped implementation and cheap subagent tasks. Using the biggest model for everything is slow and expensive; using the smallest for everything gets shallow results on hard problems.
An interactive session isn't the only way to run Claude. It can be triggered by scripts, by the clock, by GitHub events, or by you from your phone:
claude -p "prompt" runs non-interactively with JSON output formats for parsing; this is how you embed Claude in CI pipelines and pre-commit hooks./loop reruns a task on your machine at an interval (e.g., auto-addressing PR review comments every 5 minutes), while /schedule creates cloud jobs that keep working after you close your laptop./install-github-app lets anyone tag @claude in issues and PR comments. Automatic review of every PR is a separate Claude Code Review workflow you configure.Skills are folders with a SKILL.md file that give Claude domain knowledge or repeatable workflows. Claude applies them automatically when relevant, or you invoke them with /skill-name. Create one under .claude/skills/<name>/ with a name and description in frontmatter; add disable-model-invocation: true for workflows with side effects you want to trigger manually (like a /fix-issue 1234 command that pulls the issue with gh, fixes it, tests, and opens a PR).
Skills are also where "sometimes-relevant" knowledge belongs instead of CLAUDE.md, since they load on demand without bloating every session. The most popular installable skill is Anthropic's official frontend-design skill, which fixes the "every AI-generated UI looks the same" problem, by forcing Claude to commit to a specific aesthetic direction before writing code. Other high-value picks: web-design-guidelines (reviews UI code against Vercel's interface guidelines like a linter for what ESLint can't catch), doc-coauthoring, and code-simplifier. Browse the anthropics/skills repo on GitHub.
Hooks run scripts automatically at specific points in Claude's workflow, and unlike CLAUDE.md instructions, which are advisory, hooks are deterministic and guarantee the action happens. Claude can write them for you: "Write a hook that runs eslint after every file edit" or "Write a hook that blocks writes to the migrations folder." Boris Cherny (Claude Code's creator) uses PostToolUse hooks to auto-format code after edits, Claude usually formats well, but hooks handle the last 10% to avoid CI errors. Run /hooks to browse what's configured.
There are two ways to let Claude reach things outside your repo, and they have different costs. MCP (Model Context Protocol) servers are rich integrations: run claude mcp add to connect issue trackers, databases, monitoring, or design tools, and Claude gets purpose-built tools for each. The catch is that every connected server loads its tool definitions into your context window, so each one you add eats into that budget.
Plain CLI tools avoid that cost entirely: they add nothing to context until the moment Claude runs them. So the rule of thumb: use a CLI when a good one exists, reach for MCP when it doesn't. In practice, install gh and Claude already knows how to create issues, open PRs, and read comments, no server needed; for unfamiliar tools, "use foo-cli --help to learn the tool, then use it to do X." Where MCP earns its context cost: Playwright for browser testing and UI verification (setup in item 20), PostgreSQL/MySQL for direct schema queries, and Figma for design-to-code, things no CLI does well.
Plugins bundle skills, hooks, subagents, and MCP servers into a single installable unit. Run /plugin to browse the marketplace of community and Anthropic-published plugins. If you work in a typed language, a code intelligence plugin gives Claude precise symbol navigation and automatic error detection after edits.
Three ways to stop clicking "approve" all day:
/permissions allowlists - pre-approve commands you trust, like npm run lint./sandbox - OS-level restrictions, primarily around what Bash commands can reach. Note it doesn't automatically isolate every file operation, MCP server, or hook, so for genuinely untrusted or fully unattended work, run Claude inside a container, VM, or dedicated sandbox runtime instead.auth flows, payment logic, data mutations, and destructive database operations. A wrong auth scope or a migration that silently drops a column can cost you users, money, or trust, and no automated check catches every one.
Worth its own entry, because permission fatigue is the single most common reason people give up on longer Claude Code sessions. Press Shift+Tab to cycle permission modes. The full set is default (reads only), acceptEdits (adds file edits and common filesystem commands), plan, auto, dontAsk, and bypassPermissions. The status bar tells you where you are, for example ⏷⏷ auto mode on.
In auto mode a separate classifier model reviews each action before it runs and blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognize, or looks like it came from hostile content Claude just read. That is the important distinction: auto mode is reviewed, bypassPermissions is not. Bypass skips the prompts outright and is meant only for isolated containers and VMs. Auto mode also nudges Claude to keep working instead of stopping to ask clarifying questions. Set it as your default with "permissions": {"defaultMode": "auto"} in your user settings, not project settings, since a repository is not allowed to grant itself auto mode.
Heads up: as of August 14, 2026, auto mode becomes the default for new sessions on Pro, Max, and Team plans. It reduces prompts but does not guarantee safety, so keep the human-in-the-loop list above in mind. Reviewing a diff is still your job.
Two different products get confused here, so it is worth separating them.
Claude in Chrome is the one most people mean. It is a browser extension that lets Claude read, click, and navigate sites alongside you, and it can be driven from Claude Code. That gives you a real build-test-verify loop: Claude writes the code, opens the page, clicks through it, and reads the browser console logs to debug what it finds. It is available on all paid plans, and generally available in Claude Code while still beta in the browser itself.
Computer use is the API-level tool, and it is a different thing: screenshots plus mouse and keyboard control of an entire desktop, not just a browser tab. It is a beta feature you build with rather than a switch you flip in Claude Code, and Anthropic ships a reference implementation that runs inside a Docker container for a reason.
Anything that reads web pages can read instructions hidden in them, and Claude will sometimes follow those instructions even when they conflict with yours. Anthropic's own guidance is to use a dedicated VM or container with minimal privileges, avoid giving it access to sensitive data and logins, and start with sites you trust. Treat "let the agent use my browser" as a security decision, not a convenience one.
Every /clear throws away what Claude learned. CLAUDE.md is the right home for durable project rules, but it is a bad home for the messier stuff: why you rejected an approach, what a gnarly bug turned out to be, the shape of a migration you are halfway through.
Obsidian works well for this precisely because it is boring: notes are plain Markdown files stored locally on your machine, so a vault is just a folder Claude can already read and write with no plugin, no API, and no integration to maintain. Point it at the folder and ask it to check for prior notes before starting and write up what it learned when finishing. The app is free, and its linking and graph features are for you, not for Claude, which only ever sees the files. One caution: notes are worth keeping only if they get pruned, since a stale note that contradicts the codebase is worse than no note at all.
Item 8 covers worktrees and multiple sessions. The problem that shows up next is operational: agents die when you close the laptop, and once you have five running you lose track of which one is actually waiting on you.
Herdr is a background server that owns the terminals your agents run in, tmux-style but built for this specific job. Sessions survive closing the terminal, losing the network, and restarting the machine, and you can reattach from anywhere including over SSH. Each pane reports whether it is working, blocked, or idle, which is the part that matters at scale: you stop polling five windows and just look at which one needs a decision. Agents can also spawn panes and prompt each other through its CLI and socket API. It is Apache-2.0 licensed, installs with a single command or brew install herdr, and detects Claude Code out of the box alongside Codex, Cursor, opencode, and others. Reach for it once you are past two or three concurrent agents; below that a couple of terminal tabs is fine.
Item 13 lists Playwright as one of the few cases where MCP earns its context cost. Here is the actual setup. The server is Microsoft's official @playwright/mcp, and adding it is one command:
claude mcp add playwright -- npx @playwright/mcp@latest
Then run /mcp to confirm it connected. The key design detail is that it drives the page through Playwright's accessibility tree rather than screenshots, so no vision model is involved and it operates on structured data. In practice that means it is faster, cheaper, and more reliable than asking a model to squint at a picture of your UI.
What this unlocks is the difference between generated tests and real ones. Without it, Claude writes selectors from typical patterns and guesses at your markup. With it, Claude opens the page, reads the DOM, uses the selectors that actually exist, and finds out what your validation really does by triggering it. Ask it to explore a flow and then write the test from what it observed. It also covers navigation, form filling, network inspection and mocking, tab management, and trace recording, which makes it useful for reproducing a bug, not just for verifying a fix.
Unrelated tasks polluting one context. Fix: /clear.
Same issue, repeated nudges. Fix: after two failures, restart with a better prompt.
Rules get lost in noise. Fix: prune, or convert rules to hooks.
Plausible code, unhandled edge cases. Fix: if you can't verify it, don't ship it.
"Investigate the codebase" with no boundary. Fix: scope it or send a subagent.
A useful mental model for the extension mechanisms: CLAUDE.md and auto memory shape what Claude knows every session, skills change how it approaches a class of task, hooks enforce rules automatically at workflow checkpoints, MCP servers and CLI tools extend what it can reach, subagents and worktrees multiply how much it can do at once, and plugins package all of the above for one-command install.