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