Claude Code best practices that actually make a difference
Master Claude Code with proven techniques: CLAUDE.md setup, parallel sessions, subagents, custom commands, context management, and real workflow patterns from power users.
Most developers use Claude Code like a slightly smarter terminal autocomplete. They type a request, wait for a response, then move on. But power users know something different: Claude Code supports multiple concurrent sessions, persistent context, and sophisticated workflow automation that can transform how you code.
After analyzing how experts actually use Claude Code, the patterns are clear. The difference between amateur and professional usage isn't about knowing every flag or command—it's about understanding context management, workflow design, and when to use which tool. Let's explore the practices that separate beginners from power users.
What makes CLAUDE.md your most important configuration file?
Before touching any advanced features, get your CLAUDE.md right. This file is the agent's "constitution" — the primary source of truth for how your specific repository works. Every session, Claude reads it. Every session, it anchors Claude's behavior without you having to re-explain your project.
The Claude Code documentation explains that CLAUDE.md is a special file that Claude reads at the start of every conversation. Include Bash commands, code style, and workflow rules. This gives Claude persistent context it can't infer from code alone.
Here's what your CLAUDE.md should contain:
# Project: My Web App
## Build & Test Commands
- `npm run build` - Build for production
- `npm test` - Run test suite
- `npm run lint` - Check code style
## Architecture
- Frontend: React with TypeScript
- Backend: Node.js with Express
- Database: PostgreSQL with Prisma
## Conventions
- Use functional components with hooks
- TypeScript strict mode required
- No default exports
- Commit format: feat/fix/chore(scope): description
## Never Do This
- Don't use `any` type
- Don't skip error handling
- Don't commit without running tests
Run /init to generate a starter CLAUDE.md file based on your current project structure, then refine over time. The /init command analyzes your codebase to detect build systems, test frameworks, and code patterns, giving you a solid foundation to refine. There's no required format for CLAUDE.md files, but keep it short and human-readable.
The key insight from power users: every time Claude does something wrong like using the wrong library, formatting code differently than you'd like, or putting files in the wrong place — simply add a line. That's it! The file compounds over time, and eventually Claude just works the way you want it to. This reduces the number of times Claude repeats the same mistakes.
How do you run multiple sessions like a professional?
Most of us are used to running a single AI session at a time. Whether it's ChatGPT, Gemini, Perplexity or Claude, you typically open one chat, give it a task, wait for its response, and move on. I had been treating Claude Code the same way, too. I run one session in the terminal and wait for its output before moving on to the next thing. Boris Cherny, though, does something completely different. He runs 10 to 15 sessions at a single time!
Launch multiple Claude Code instances in parallel, each dedicated to a specific task, to multiply your processing capacity without saturating a single context window. Horizontal scaling involves distributing work across multiple independent sessions rather than loading everything into a single 200,000-token window. Each session has its own token budget.
Here's the practical approach:
# Terminal 1: Feature development
claude "Implement user authentication with JWT"
# Terminal 2: Testing
claude "Write comprehensive tests for the auth module"
# Terminal 3: Documentation
claude "Generate API documentation for auth endpoints"
# Terminal 4: Code review
claude "Review the auth implementation for security issues"
Beyond parallelizing work, multiple sessions enable quality-focused workflows. A fresh context improves code review since Claude won't be biased toward code it just wrote. For example, use a Writer/Reviewer pattern: You can do something similar with tests: have one Claude write tests, then another write code to pass them.
The Claude Code settings documentation shows you can configure different models per session:
claude --model claude-opus-4-6 # For complex planning
claude --model claude-sonnet-4-6 # For routine coding tasks
What's the right way to manage your context window?
Claude models support up to 200,000 tokens in the context window, but real-world usage hovers far lower for efficiency. The reality is that the more information you put into the context, the worse the results can become. In practice, when working with AI agents we are always balancing between providing enough context to solve the task and overloading the context window. That is why we should always aim to describe the task in the smallest and most concise way possible.
Power users follow specific patterns:
Use /clear liberally: Pro tip: use /clear often. Every time you start something new, clear the chat. You don't need all that history eating your tokens, and you definitely don't need Claude running compaction calls to summarize old conversations.
Monitor your context: A session that stays within its context budget produces better code than one that compacts three times to limp across the finish line. When you notice context running low (check the statusline — green >50%, yellow >20%, red below), it's time to wrap up and start a new session, not push through.
Prefer /clear over /compact: Prefer /clear over /compact. /clear wipes the conversation and starts fresh. /compact summarizes and continues. Default to /clear between tasks. /compact is useful when you're mid-task and need to reclaim space without losing your place, but each compaction is a lossy compression — details get dropped. Two compactions in a session is a sign the task was too large. /clear has no information loss because there's nothing to lose — your CLAUDE.md reloads.
The context management commands you'll use most:
/clear # Start fresh, keep CLAUDE.md
/compact # Summarize history (lossy)
/context # Check token usage
/resume <name> # Return to saved session
/rename # Name current session
When should you use subagents vs staying in the main session?
On paper, custom subagents are Claude Code's most powerful feature for context management. The pitch is simple: a complex task requires X tokens of input context (e.g., how to run tests), accumulates Y tokens of working context, and produces a Z token answer. Running N tasks means (X + Y + Z) * N tokens in your main window. The subagent solution is to farm out the (X + Y) * N work to specialized agents, which only return the final Z token answers, keeping your main context clean.
But there's a catch. In practice, custom subagents create two new problems: They Gatekeep Context: If I make a PythonTests subagent, I've now hidden all testing context from my main agent. It can no longer reason holistically about a change. It's now forced to invoke the subagent just to know how to validate its own code. They Force Human Workflows: Worse, they force Claude into a rigid, human-defined workflow.
The Claude Code subagents documentation shows how to create custom subagents:
/agents # Interactive subagent manager
Select Create new agent, then choose Personal. This saves the subagent to ~/.claude/agents/ so it's available in all your projects.
The power user recommendation: Custom subagents are a brittle solution. Give your main agent the context (in CLAUDE.md) and let it use its own Task/Explore(...) feature to manage delegation.
Use subagents for:
- Code review: Fresh context prevents bias toward code just written
- Isolated tasks: Database queries, API testing, documentation generation
- Parallel processing: When you need true separation of concerns
Stay in main session for:
- Holistic changes: Features that touch multiple parts of your codebase
- Iterative development: When context builds up naturally
- Debugging: Where understanding the full problem requires all available context
How do you create powerful custom slash commands?
You can create your own CC slash commands. This is a good "shortcut" for pulling up a common prompt. Again, the more context the better (but also keep these abstract so they can be widely applied).
You can also add custom slash commands pretty easily. To add commands, just create a .claude/commands folder, add the command name as a file with a .md extension. You just write these in natural language and you can use the $ARGUMENTS string to place arguments into the prompt.
Here are practical examples from power users:
# Create project-specific command
mkdir -p .claude/commands
echo "Fix issue #$ARGUMENTS following our coding standards" > .claude/commands/fix-issue.md
# Create personal command for all projects
mkdir -p ~/.claude/commands
echo "Review this code for security vulnerabilities:" > ~/.claude/commands/security.md
Advanced commands can orchestrate complex workflows. If you want a slash command that explicitly launches multiple subagents in parallel and then produces an artifact (like a research note), you can encode that directly in the command definition:
---
description: Research a problem using multiple approaches
allowed-tools: Task, WebSearch, Read, Write, Bash
---
# Research: $ARGUMENTS
## Instructions
Launch multiple subagents in parallel to gather information:
1. **Web Documentation Agent** - Search official docs
2. **Codebase Explorer** - Analyze existing patterns
3. **Test Runner** - Verify current behavior
Consolidate findings into a research report.
The key insight: Most commands either invoke subagents (workflow shortcuts) or run simple bash scripts (utility shortcuts). They're the fastest way to start frequently-used workflows. Instead of typing "Can you help me create a skill?" you just type /create-skill and the workflow starts immediately.
What are the essential workflow patterns for git integration?
Tell Claude Code to use CLI tools like gh, aws, gcloud, and sentry-cli when interacting with external services. CLI tools are the most context-efficient way to interact with external services. If you use GitHub, install the gh CLI. Claude knows how to use it for creating issues, opening pull requests, and reading comments.
Essential setup for git workflows:
- Install GitHub CLI:
brew install ghor visit GitHub CLI - Configure Claude for git: Add this to your CLAUDE.md:
## Git Workflow
- Use `gh pr create` for pull requests
- Run tests before any commit
- Use conventional commit format
- Always include issue numbers in commit messages
## Common Commands
- `gh pr create --title "feat: add user auth" --body "Fixes #123"`
- `gh issue list --state open`
- `git log --oneline -10`
One of the cooler slash commands is /install-github-app. After you run it, Claude will automatically reviews your PRs. This is actually useful because as you use more AI tools, your PR volume increases. And honestly? Claude often finds bugs that humans miss. Humans nitpick variable names. Claude finds actual logic errors and security issues.
Set up automated PR reviews:
/install-github-app
The key is customizing the review prompt. Out of the box, it's way too verbose and comments on every little thing. Claude will add a claude-code-review.yml file with a prompt already in it:
# claude-code-review.yml
direct_prompt: |
Please review this pull request and look for bugs and security issues.
Only report on bugs and potential vulnerabilities you find.
Be concise.
How do you handle permission modes safely?
Sandboxing: enable OS-level isolation that restricts filesystem and network access, allowing Claude to work more freely within defined boundaries. Alternatively, use --dangerously-skip-permissions to bypass permission prompts for contained workflows like fixing lint errors or generating boilerplate. Letting Claude run arbitrary commands can result in data loss, system corruption, or data exfiltration via prompt injection. Only use --dangerously-skip-permissions in a sandbox without internet access.
I recommend paying attention to the --permission-mode flag, as it allows you to control how Claude Code interacts with files and tool calling. For example, you can run Claude Code in a mode where it will automatically perform any actions on files and call any tools without asking. Of course, this is very dangerous and should only be used in an isolated environment, but it provides maximum autonomy.
Safe permission strategies:
# Conservative: Ask for everything (default)
claude
# Sandbox mode: OS-level isolation
claude --sandbox
# Skip permissions: Use in containers only
claude --dangerously-skip-permissions
# Selective permissions: Specify allowed tools
claude --allowed-tools Read,Write,Bash
Every time I open Claude Code, I hit Command+C and run claude --dangerously-skip-permissions. It's not as dangerous as it sounds — think of it as Cursor's old yolo mode. Could a rogue agent theoretically run a destructive command? Sure. Have I seen it happen in weeks of usage? Never. Your call on the risk tolerance, but I sleep fine at night.
The professional approach: At Trail of Bits we run Claude Code in bypass-permissions mode (--dangerously-skip-permissions). This means you need to understand your sandboxing options — the agent will execute commands without asking, so the sandbox is what keeps it from doing damage. Claude Code has a native sandbox that provides filesystem and network isolation using OS-level primitives.
What advanced techniques separate power users from beginners?
Planning Mode: Using this regularly builds a strong intuition for what minimal context is needed to get a good plan without Claude botching the implementation. In our work monorepo, we've started rolling out a custom planning tool built on the Claude Code SDK. It's similar to native plan mode but heavily prompted to align its outputs with our existing technical design format. It also enforces our internal best practices. Always use the built-in planning mode for complex changes to align on a plan before the agent starts working.
Resume and Historical Context: On a simple level, I use claude --resume and claude --continue frequently. They're great for restarting a bugged terminal or quickly rebooting an older session. I'll often claude --resume a session from days ago just to ask the agent to summarize how it overcame a specific error, which I then use to improve our CLAUDE.md and internal tooling. Claude Code stores all session history in ~/.claude/projects/ to tap into the raw historical session data. I have scripts that run meta-analysis on these logs, looking for common exceptions, permission requests, and error patterns to help improve agent-facing context.
Hooks for Automation: The practical hook strategy: block at submit time, not at write time. Avoid blocking-at-write hooks on Edit or Write operations — let the agent finish its plan, then check the final result. Blocking mid-edit breaks Claude's reasoning chain. Use hooks for formatting, logging, pre-commit validation, and desktop notifications when long tasks complete. Do not use them to replace logic that belongs in CLAUDE.md.
Context Optimization: Key takeaway: 30 to 45-minute sessions with precise objectives produce better results than a marathon session. Mastering the 200,000-token window, automatic compaction, and Plan mode lets you reduce your costs by 40 to 60% while getting more precise results.
The reality check: Most people use Claude Code like a slightly smarter terminal autocomplete. They type a request, wait for a response, and move on. But Claude Code has a full extensibility stack: slash commands, hooks, skills, subagents, MCP servers, and plugins. Each one solves a different problem. Understanding which to reach for, and when, is what separates reactive usage from actually building a system.
These practices transform Claude Code from a conversational coding assistant into a systematic development environment. The key insight isn't about memorizing commands—it's about building workflows that compound over time. Your CLAUDE.md gets smarter, your custom commands handle repetitive tasks, and multiple sessions let you think in parallel rather than sequentially.
Start with your CLAUDE.md file, add one custom command for your most common workflow, and experiment with running two sessions simultaneously. That foundation will teach you more about effective Claude Code usage than any list of advanced flags or configuration options.