Claude Code Best Practices: How the Creator Uses It

Boris, the creator of Claude Code, recently shared a thread on X detailing exactly how he uses the tool every day. These aren't generic tips — they're battle-tested practices from the person who built it. Whether you're just getting started or already deep into Claude Code, there's something here for everyone.

Let's break down his 13 key practices.

Run Multiple Sessions in Parallel

Boris doesn't use a single Claude Code session at a time. He runs 5 local instances alongside 5-10 web-based Claude sessions simultaneously. This parallelism is central to how he works — delegating different tasks to different sessions rather than waiting for one to finish.

Key techniques he uses for managing this:

• System notifications — He enables notifications so he knows when a session needs attention or finishes a task
• Background handoff with & — Launch Claude Code in the background with the & operator so your terminal stays free
• --teleport — This flag lets you start a session that can be picked up from another device or location

# Start a session in the background
claude "refactor the auth module" &
 
# Start a teleportable session
claude --teleport

The mental model is closer to managing a team than using a single tool. Each session gets a focused task, and you orchestrate across them.

Use Opus with Thinking for Everything

When it comes to model selection, Boris keeps it simple: Opus with extended thinking, all the time. He doesn't switch between models for different tasks.

His reasoning is straightforward — Opus with thinking produces the highest quality output, and the slight increase in latency is worth the improvement in reasoning, planning, and code quality. When you're running multiple sessions in parallel, the latency matters even less since you're not blocked on any single response.

CLAUDE.md as Shared Team Knowledge

Boris treats CLAUDE.md not as a personal config file, but as shared team infrastructure. His approach:

• Check CLAUDE.md into git — It lives in the repository, versioned alongside the code
• Everyone on the team contributes — When someone discovers a useful pattern or convention, they add it to CLAUDE.md
• Reference in PR reviews — Use @.claude mentions in pull request reviews to point out when code doesn't follow the conventions documented in CLAUDE.md

This transforms CLAUDE.md from a solo productivity hack into a living document of team standards. Every Claude Code session, for every team member, automatically follows the same conventions.

# CLAUDE.md (checked into repo root)
 
## Code Style
- Use functional components with TypeScript
- Prefer named exports over default exports
- All API routes must include error handling middleware
 
## Testing
- Every new feature needs unit tests
- Use MSW for API mocking in tests
 
## Architecture
- Follow the repository pattern for data access
- Keep business logic out of route handlers

Start Every Session in Plan Mode

Boris's workflow always begins the same way: Plan mode first, execute second. In Claude Code, you can enter Plan mode by pressing Shift+Tab twice.

The workflow:

1. Enter Plan mode at the start of every session
2. Describe what you want and let Claude create a detailed plan
3. Iterate on the plan — ask questions, refine the approach, adjust scope
4. Only then switch to auto-accept and let Claude execute

This prevents the common failure mode where Claude charges ahead with a wrong approach and you waste time undoing it. Planning is cheap; re-doing work is expensive.

Create Custom Slash Commands

Boris makes heavy use of custom slash commands stored in .claude/commands/. These are reusable workflows that encode common patterns.

His go-to example is a combined commit-push-PR command:

<!-- .claude/commands/commit-push-pr.md -->
 
Run the following steps:
1. Stage all changes with `git add -A`
2. Generate a descriptive commit message based on the diff
3. Commit and push to the current branch
4. Create a PR with a summary of all changes
 
Use `gh pr create` for the PR step.

A powerful technique Boris uses is inline bash within commands to pre-compute context. Instead of having Claude figure out what changed, the command can include bash snippets that gather information upfront:

<!-- .claude/commands/review-changes.md -->
 
Here are the current changes:
```bash
git diff --stat

Review these changes for:

• Security issues
• Performance problems
• Missing error handling

 
These commands are checked into `.claude/commands/` in the repo, so the whole team benefits.
 
## Leverage Subagents for Complex Workflows
 
**Subagents** are specialized Claude Code instances that handle specific sub-tasks. Boris uses them to automate repetitive workflows:
 
- **code-simplifier** — A subagent focused on reducing complexity in code, removing unnecessary abstractions and simplifying logic
- **verify-app** — Runs after changes to verify the application still works correctly
- **PR automation** — Subagents that handle common pull request workflows like generating descriptions, running checks, and flagging issues
 
The key insight is that subagents let you encode expert judgment into repeatable processes. Instead of manually reviewing every PR for the same patterns, a subagent handles it consistently.
 
## Set Up Hooks for Automation
 
**Hooks** are one of Claude Code's most powerful features, and Boris relies on two in particular:
 
### PostToolUse Hook — Auto-Format on Save
 
Every time Claude writes or edits a file, a PostToolUse hook automatically runs the formatter. This means Claude's output is always properly formatted without needing to ask for it.
 
```json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "npx prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

Stop Hook — Verification on Completion

When Claude finishes a task and stops, a hook can automatically trigger verification steps — running tests, checking types, or validating the build.

{
  "hooks": {
    "Stop": [
      {
        "command": "npm run typecheck && npm run test"
      }
    ]
  }
}

This creates a tight feedback loop where Claude automatically catches its own mistakes before you even review the output.

Configure Permissions Thoughtfully

Boris has a strong opinion here: use /permissions instead of --dangerously-skip-permissions. The dangerous flag exists for specific automation scenarios, not for daily development.

The /permissions command lets you configure granular access controls — which tools Claude can use, which directories it can access, which commands it can run — without disabling safety entirely.

His recommended approach:

• Share .claude/settings.json in the repository so the whole team has consistent permissions
• Allow specific tools and commands rather than blanket access
• Review permissions periodically as project needs change

{
  "permissions": {
    "allow": [
      "Read",
      "Write",
      "Edit",
      "Bash(npm run *)",
      "Bash(git *)",
      "Bash(npx prettier *)"
    ]
  }
}

Integrate Your Tools via MCP

Boris connects Claude Code to his broader toolchain using MCP (Model Context Protocol) servers, and shares the configuration with the team via .mcp.json.

His key integrations:

• Slack MCP — Claude can read and send Slack messages, useful for automated notifications or pulling context from team discussions
• BigQuery — Direct access to analytics data for data-informed decisions during development
• Sentry — Claude can look up error reports and stack traces when debugging issues

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@anthropic/slack-mcp"],
      "env": {
        "SLACK_TOKEN": "${SLACK_TOKEN}"
      }
    },
    "sentry": {
      "command": "npx",
      "args": ["-y", "@anthropic/sentry-mcp"]
    }
  }
}

By checking .mcp.json into the repo, every team member gets the same integrations automatically.

Handle Long-Running Tasks Smartly

Some tasks take a while — large refactors, comprehensive test suites, complex migrations. Boris has specific strategies for these:

• Background agents — Start long-running tasks in the background and check on them later
• ralph-wiggum plugin — A community plugin that helps manage and monitor long-running Claude Code sessions
• --permission-mode=dontAsk — Used specifically in sandboxed environments where automated execution is safe. Boris emphasizes this should only be used in proper sandboxes, not in your main development environment

# In a sandboxed CI/CD environment
claude --permission-mode=dontAsk "run the full test suite and fix any failures"

The distinction matters: use proper permission controls for interactive work, and only use unrestricted modes in environments where the blast radius is contained.

Verification is the Biggest Force Multiplier

This is Boris's most emphatic recommendation: always give Claude a way to verify its own work. He claims this alone provides a 2-3x quality improvement.

The principle is simple — if Claude can check whether its changes actually work, it can iterate and fix problems before presenting the result to you. Without verification, you're relying entirely on the model's first-pass accuracy.

Ways to enable verification:

• Test suites — If your project has tests, Claude can run them after making changes
• Browser testing — For frontend work, let Claude verify visual output
• Bash commands — Type checking, linting, build verification
• Custom verification scripts — Project-specific checks that validate correctness

# A verification-enabled workflow
claude "Add user avatar upload. After implementing, run the test suite
with 'npm test' and fix any failures. Then run 'npm run build' to
verify the build succeeds."

The key insight: verification transforms Claude from a code generator into a code developer. A developer writes code, tests it, finds bugs, and fixes them. That's exactly what Claude does when given verification tools.

Putting It All Together

Boris's setup isn't about any single tip — it's about how these practices compound. Here's what a typical workflow looks like with all of these in place:

1. Start in Plan mode to align on approach
2. CLAUDE.md ensures consistent conventions across the team
3. Slash commands handle repetitive workflows in one step
4. Hooks auto-format and verify as Claude works
5. Multiple parallel sessions keep you unblocked
6. MCP integrations give Claude access to your full toolchain
7. Verification catches issues before you even review

Each practice makes the others more effective. Verification is more powerful when combined with hooks. Parallel sessions are more useful when each has proper CLAUDE.md context. Slash commands are more valuable when shared across the team.

The throughline across all of Boris's advice is this: treat Claude Code as a team member, not a tool. Give it context (CLAUDE.md), give it workflows (slash commands, hooks), give it access (MCP, permissions), and give it accountability (verification). The more you invest in the setup, the more autonomy you can safely grant — and the more productive you become.

These tips are based on Boris's public thread on X. For the latest Claude Code features and documentation, visit the official Claude Code docs.