Claude Code is Anthropic’s official CLI for Claude — a terminal-first AI coding assistant that reads your codebase, edits your files, runs your commands, and reasons through complex engineering problems. It is not an autocomplete plugin. It is more like pairing with a senior engineer who never gets tired, never forgets your project conventions, and can hold an entire codebase in working memory.

But like any powerful tool, most people are only scratching the surface. This guide covers everything: the foundational setup that compounds over time, the advanced workflows that separate casual users from power users, and the team-level strategies that make Claude Code a force multiplier across an entire engineering organisation.

Getting started: the explore-plan-code-commit loop

Before diving into features, it helps to understand the fundamental workflow that produces the best results with Claude Code. Think of it as a loop with four phases:

1. Explore — Ask Claude to read and understand the relevant parts of your codebase. Let it use subagents to search broadly without polluting your main conversation context.
2. Plan — Switch to Plan Mode (press Shift+Tab or use /plan). Have Claude propose its approach, identify edge cases, and map dependencies — without touching any files.
3. Code — Switch back to implementation mode and let Claude execute the plan. It will read, edit, write files, and run commands.
4. Commit — Use /commit to review changes and generate a well-structured commit message.

This loop is not just a suggestion — it is the single most important habit for getting reliable output. Planning before coding reduces rework by an order of magnitude.

CLAUDE.md: teaching Claude your project

CLAUDE.md is the persistent instruction system that tells Claude how your project works. Think of it as a living style guide that Claude reads at the start of every session. It is the highest-leverage configuration you can set up, because good instructions compound: every session benefits from what you wrote once.

The three scopes

CLAUDE.md files work at three levels, each with a clear purpose:

Scope	Location	Shared?	Purpose
Project	./CLAUDE.md or .claude/CLAUDE.md	Yes (checked into git)	Project conventions, build commands, architecture decisions
User	~/.claude/CLAUDE.md	No (personal)	Personal code style preferences, editor habits
Managed	System-level path	Yes (IT-deployed)	Organisation-wide policies

The precedence flows from managed (highest) through project to user (lowest), so organisation policies always win.

What belongs in CLAUDE.md

The best CLAUDE.md files are concise, specific, and actionable. Here is an example:

# Build & Test

- Build: `npm run build`
- Test: `npm run test`
- Single test: `npm run test -- --filter <name>`
- Lint: `npm run lint -- --fix`

# Code Style

- TypeScript strict mode, no `any` types
- 2-space indentation, single quotes
- Prefer named exports over default exports
- Use functional patterns; avoid classes unless wrapping external APIs

# Architecture

- All API routes in `src/routes/` follow REST conventions
- Database access through repository pattern in `src/repos/`
- Shared types in `src/types/` — never import from implementation files

# Git

- Conventional commit messages (feat:, fix:, refactor:, etc.)
- Always create a new branch for feature work
- Run `npm run test` before committing

What does not belong

Do not put anything in CLAUDE.md that Claude can infer from reading your code. File paths it can discover, patterns it can see in your imports, test frameworks it can detect from config files — all of this is noise that dilutes the important instructions. Keep it under 200 lines. The longer it gets, the less reliably Claude follows every instruction.

Generating a starter CLAUDE.md

If you are starting from scratch, run /init. Claude will scan your project structure, detect your build tools, identify conventions from existing code, and generate a sensible starting point. You can then refine it from there.

Modular rules with .claude/rules/

For larger projects, you can split instructions into separate files inside .claude/rules/. Each rule file can be scoped to specific file patterns using frontmatter:

---
globs: ["src/components/**/*.tsx"]
---

- All components must accept a `className` prop
- Use `forwardRef` for components that render DOM elements
- Co-locate tests in `__tests__/` subdirectory

This keeps your root CLAUDE.md clean while providing targeted guidance for different parts of the codebase.

Prompt contracts: making Claude’s output predictable

A prompt contract is a technique for making AI output deterministic and verifiable. Rather than hoping Claude produces what you want, you define the contract upfront — what success looks like, how to verify it, and what constraints must hold — and then let Claude work towards that contract.

The anatomy of a prompt contract

A prompt contract has three parts:

1. Specification — What you want, described precisely. Not “make a login page” but “create a login page at /login that accepts email and password, validates both fields client-side, calls POST /api/auth/login, and redirects to /dashboard on success.”

2. Verification criteria — How Claude (and you) can confirm the work is correct. The most powerful version of this is existing tests: “the work is done when npm run test passes.” But it can also be type checking (tsc --noEmit), linting, or even “take a screenshot and verify the layout matches this description.”

3. Constraints — Boundaries that must not be violated. “Do not modify any files outside src/auth/.” “Do not add new dependencies.” “Do not change the public API surface.”

Why prompt contracts work

Claude Code has a built-in loop: it takes an action, observes the result, and decides what to do next. When you give it verification criteria, you are giving it a feedback loop — it can run the tests, see failures, and iterate until they pass. Without verification criteria, Claude has no way to self-check and must guess when it is done.

Prompt contract in practice

Here is an example of a well-structured prompt with an implicit contract:

Add rate limiting to the /api/upload endpoint.

Requirements:
- Max 10 requests per minute per authenticated user
- Max 3 requests per minute for anonymous users
- Return 429 with a Retry-After header when limited
- Use the existing Redis client from src/lib/redis.ts

Verification:
- All existing tests in tests/api/upload.spec.ts must still pass
- Add new tests for both rate limit scenarios
- Run: npm run test -- --filter upload

Constraints:
- Do not modify any other API endpoints
- Do not add new npm dependencies

Claude will read the relevant files, implement the rate limiter, write the tests, run them, fix any failures, and keep iterating until the verification criteria are met. The entire process is self-correcting.

Building contracts into CLAUDE.md

You can embed recurring contracts directly in your CLAUDE.md:

# Verification

After any code change:
1. Run `npm run typecheck` — must pass with zero errors
2. Run `npm run test` — must pass with zero failures
3. Run `npm run lint` — must pass (auto-fix is acceptable)

This turns every session into a contract-driven workflow without you having to specify it each time.

Slash commands: your workflow shortcuts

Claude Code ships with a library of slash commands that streamline common workflows. Here are the ones that matter most:

Essential commands

Command	What it does
/init	Generates a starter CLAUDE.md by scanning your project
/plan	Switches to Plan Mode — Claude explores and proposes without modifying files
/compact	Compresses conversation history to free context window space
/clear	Resets context entirely — use between unrelated tasks
/review	Reviews code changes or PRs for issues
/commit	Stages changes and creates a well-structured commit
/model	Switch between models (Opus, Sonnet, Haiku)
/memory	View and edit CLAUDE.md files and auto-memory
/help	Shows all available commands and keyboard shortcuts

Less obvious but powerful

Command	What it does
/resume	Resume a previous conversation with full context
/rename	Give the current session a memorable name for later
/add-dir	Add additional directories for Claude to access (useful for monorepos)
/hooks	Configure lifecycle hooks interactively
/mcp	Configure MCP server connections
/config	Access the settings interface
/status	Check which settings sources are active and their precedence
/doctor	Run diagnostics to check system health and configuration warnings

Custom slash commands via skills

You can define your own reusable slash commands by creating skill files in .claude/skills/. These act like saved prompts that your entire team can use.

Keyboard shortcuts: staying in flow

The fastest Claude Code users rarely reach for slash commands — they use keyboard shortcuts. Here are the ones worth memorising:

Shortcut	Action
Enter	Submit your message
Escape	Cancel current input
Shift+Tab	Cycle through permission modes
Ctrl+T	Toggle the task list
Ctrl+B	Send current task to background
Ctrl+R	Search conversation history
Ctrl+O	Toggle verbose transcript (see Claude’s thinking)
Ctrl+G	Open current prompt in external editor
Ctrl+S	Stash your current prompt for later
Ctrl+\	Undo the last action
Esc Esc	Rewind to a previous state (undo checkpoint)
Alt+T	Toggle extended thinking
Ctrl+C	Interrupt Claude mid-response
Ctrl+D	Exit Claude Code

All shortcuts are customisable via ~/.claude/keybindings.json. You can even create chord bindings (e.g., Ctrl+K Ctrl+S) for actions you use frequently.

Permission modes: balancing safety and speed

Claude Code offers five permission modes that control how much autonomy Claude has. Understanding these is critical for both safety and productivity.

Mode	Behaviour
default	Prompts you for approval on every tool use
acceptEdits	Auto-approves file edits, still prompts for Bash commands
plan	Read-only — Claude can explore but cannot modify anything
dontAsk	Auto-denies unless you have pre-approved specific tools
bypassPermissions	Skips all checks (only available with OS-level sandboxing)

Press Shift+Tab to cycle between modes during a session, or start in a specific mode:

claude --permission-mode plan

Fine-grained permission rules

For more control, define permission rules in your settings:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Read(src/**)",
      "Edit(src/**)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(.env*)",
      "Bash(curl *)",
      "Bash(rm -rf *)"
    ]
  }
}

The precedence is deny > ask > allow — deny rules always win. This lets you give Claude broad autonomy for safe operations while maintaining guardrails around destructive or sensitive actions.

Model selection and effort levels

Claude Code supports multiple models, each suited to different tasks:

Model	Best for
Opus 4.6	Complex reasoning, large refactors, architectural decisions
Sonnet 4.6	Day-to-day coding, balanced speed and capability
Haiku 4.5	Quick queries, simple edits, fast turnaround

Switch models with /model sonnet or at startup with claude --model opus.

Adaptive reasoning and effort levels

Both Opus 4.6 and Sonnet 4.6 support adaptive reasoning with configurable effort levels:

• low — Faster and cheaper, good for straightforward tasks
• medium — Balanced (the default)
• high — Deeper reasoning for genuinely complex problems

You can set this in your settings or via the environment variable CLAUDE_CODE_EFFORT_LEVEL.

Extended context

For long sessions or massive codebases, you can activate the 1M token context window:

claude --model sonnet[1m]

This gives Claude four times the standard context, at the cost of slightly higher latency on long conversations.

Hooks: deterministic automation

Hooks are the most underrated feature in Claude Code. They let you run shell commands, HTTP calls, or even LLM-powered evaluations at specific points in Claude’s lifecycle. Unlike instructions in CLAUDE.md (which Claude may interpret flexibly), hooks execute deterministically every time.

Hook events

Claude Code exposes a rich set of lifecycle events:

Event	When it fires
SessionStart	When a session begins or resumes
UserPromptSubmit	Before Claude processes your input
PreToolUse	Before a tool executes (can block it)
PostToolUse	After a tool succeeds
Stop	When Claude finishes responding
PreCompact	Before context compression
Notification	When Claude needs your attention

Practical hook examples

Auto-format after every edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "type": "command",
        "command": "npx prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

Block edits to protected files:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit",
        "type": "command",
        "command": "echo $CLAUDE_FILE_PATH | grep -q 'migrations/' && echo 'BLOCK: Do not edit migration files directly' && exit 1 || exit 0"
      }
    ]
  }
}

Desktop notification when Claude needs input:

{
  "hooks": {
    "Notification": [
      {
        "type": "command",
        "command": "notify-send 'Claude Code' 'Needs your attention'"
      }
    ]
  }
}

Hooks are configured in your settings files (~/.claude/settings.json for personal, .claude/settings.json for project-level) and can use four different types: command (shell), http (webhook), prompt (single-turn LLM check), and agent (multi-turn verification).

MCP servers: extending Claude’s reach

By default, Claude Code can read files, edit code, and run shell commands — but it has no awareness of your wider infrastructure. It cannot query your database, check your error tracker, read your design specs, or look up a ticket in your project management tool. Every time you need information from one of those systems, you are the bottleneck: you switch tabs, copy data, paste it into the conversation, and hope you grabbed enough context.

The Model Context Protocol (MCP) eliminates that bottleneck. MCP is an open standard that lets Claude connect directly to external tools and services through a simple server interface. Each MCP server exposes a set of tools — query a database, list Sentry errors, read a Figma frame, search Slack messages — and Claude can call them as naturally as it calls Read or Bash. The result is that Claude stops being a tool that only sees your code and becomes one that sees your entire development ecosystem.

How MCP works in practice

An MCP server is a lightweight process that speaks a standard protocol. It can run locally on your machine (as a subprocess that communicates over stdin/stdout), or remotely as an HTTP endpoint. When Claude Code starts a session, it connects to your configured MCP servers, discovers what tools they offer, and makes those tools available alongside its built-in ones.

From your perspective, the experience is seamless. You ask Claude a question, and if the answer requires data from an external system, Claude calls the appropriate MCP tool, gets the result, and continues reasoning. You do not need to know which MCP server provided the data — Claude handles the routing.

Adding MCP servers

There are three transport types depending on how the server runs:

# Remote HTTP server (most common for cloud services)
claude mcp add --transport http github https://api.github.com/mcp

# Local stdio server (runs as a subprocess on your machine)
claude mcp add --transport stdio postgres -- npx @modelcontextprotocol/server-postgres

# SSE server (older streaming protocol, being superseded by HTTP)
claude mcp add --transport sse sentry https://sentry.io/api/mcp/sse

For servers that require authentication, Claude handles OAuth flows automatically. Run /mcp to authenticate with remote servers — tokens are stored securely and refreshed when they expire.

Three scopes for MCP configuration

Like most Claude Code configuration, MCP servers can be set up at different levels:

Scope	Location	Use case
Local (default)	~/.claude.json	Personal tools — your own database, your Sentry account
Project	.mcp.json in repo root	Team-shared tools — the project database, shared Figma files
User	~/.claude.json	Tools you want across all projects — personal Notion, Slack

Project-level MCP via .mcp.json

For team-shared integrations, add a .mcp.json to your repository root and check it into git. Every team member who clones the repo gets the same MCP connections:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${DATABASE_URL}"
      }
    },
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Environment variables are expanded at runtime using ${VAR_NAME} syntax, so secrets stay in each developer’s local environment rather than in checked-in config.

Practical examples: what MCP unlocks

Here are concrete scenarios where MCP transforms the Claude Code experience from good to indispensable.

Database queries without leaving the conversation

Without MCP: You open a database client, write a query, copy the results, paste them into Claude, and ask your question.

With MCP (PostgreSQL server):

> What's causing the spike in failed payments this week?
> Check the payments table for error patterns since Monday.

Claude calls the PostgreSQL MCP server, runs a query against your payments table, analyses the error distribution, and tells you that 73% of failures are card_declined from a single payment processor that started returning errors on Tuesday. It then offers to check your integration code for that processor.

Setup:

claude mcp add --transport stdio postgres -- npx @modelcontextprotocol/server-postgres

The server uses your DATABASE_URL environment variable and exposes tools like query (run read-only SQL), list_tables, and describe_table. Claude can explore your schema, understand relationships, and write precise queries — all without you copying a single result.

Triaging errors from your monitoring stack

Without MCP: You open Sentry, scroll through errors, copy stack traces, paste them into Claude, and ask for analysis.

With MCP (Sentry server):

> We're getting reports of 500 errors on the checkout page.
> Check Sentry for recent unresolved issues affecting the checkout flow.

Claude queries Sentry for recent errors matching the checkout endpoints, reads the stack traces, identifies the root cause (a null pointer in the shipping calculation when the cart has digital-only items), finds the offending code in your repository, and proposes a fix — all in one conversation turn.

Working with GitHub issues and PRs

Without MCP: You browse GitHub, read the issue, copy relevant details, then ask Claude to implement it.

With MCP (GitHub server):

> Pick up issue #247 and implement it.

Claude reads the issue description, checks linked issues and PR comments for context, reads the referenced files in your codebase, implements the change, runs the tests, and opens a PR that references the original issue. The entire workflow — from reading the ticket to opening the PR — happens in a single conversation.

Setup:

claude mcp add --transport stdio github -- npx @modelcontextprotocol/server-github

Implementing designs from Figma

Without MCP: You screenshot the design, describe the layout, and iterate back and forth as Claude approximates what you want.

With MCP (Figma server):

> Implement the new pricing card from the Figma file.
> The frame is called "Pricing Card - Enterprise" in the Components page.

Claude reads the Figma frame directly — dimensions, colours, typography, spacing, component hierarchy — and generates pixel-accurate CSS and markup on the first pass. When the design changes, Claude can re-read the frame and update the implementation to match.

Searching team conversations for context

Without MCP: You search Slack manually, copy relevant messages, and provide them as context.

With MCP (Slack server):

> The team discussed changing the session timeout last week.
> Find that conversation and tell me what was decided.

Claude searches the relevant Slack channels, finds the discussion thread, extracts the decision (increase timeout to 30 minutes for enterprise users, keep 15 minutes for free tier), and can immediately implement the configuration change if you approve.

Infrastructure and cloud operations

With MCP (AWS server):

> Check if the staging environment's Lambda functions are running
> the latest deployment. Compare the function versions with what's
> in our terraform state.

Claude queries AWS Lambda for deployed function configurations, compares versions against your infrastructure-as-code definitions, and flags any drift — functions still running old code, environment variables that don’t match, or memory allocations that differ from the declared state.

Building your own MCP server

If your team uses internal tools that don’t have a public MCP server, building one is straightforward. An MCP server is essentially a function that:

1. Declares what tools it offers (name, description, input schema)
2. Handles tool calls and returns results

The MCP specification provides SDKs for TypeScript and Python. A minimal server that wraps an internal API might be 50-100 lines of code. Once built, you add it to your .mcp.json and every team member has access to Claude-powered interactions with your internal systems.

When to use MCP vs. shell commands

A common question is: “Why not just use Bash to call APIs directly?” You can — curl, database CLIs, and cloud CLIs all work through the Bash tool. MCP servers offer advantages when:

• Authentication is complex — OAuth flows, token refresh, and credential management are handled by the server
• The tool surface is rich — A good MCP server exposes well-typed tools with descriptions that help Claude choose the right operation
• You want team consistency — .mcp.json ensures everyone connects to the same services the same way
• You need safety guardrails — MCP servers can enforce read-only access, rate limits, or scope restrictions that raw shell commands cannot

For quick one-off queries, Bash is fine. For integrations your team uses daily, MCP servers are worth the setup.

The memory system: Claude that learns

Claude Code has a two-part memory system that gets smarter the more you use it.

CLAUDE.md (you write)

As covered above, this is the explicit instruction set you author. It is loaded at the start of every session, survives context compression, and is the most reliable way to steer Claude’s behaviour.

Auto-memory (Claude writes)

Claude also maintains its own memory, stored in ~/.claude/projects/<project>/memory/. When Claude learns something important about your project — your preferences, architectural decisions, common pitfalls — it can save that to memory files that persist across sessions.

The first 200 lines of the memory index are loaded into every conversation, giving Claude a persistent understanding of your project that grows over time.

Managing memory

• Run /memory to view and edit memory files
• Ask Claude to “remember that we always use UTC timestamps” and it will save it
• Ask Claude to “forget the note about the old database” and it will remove it
• Auto-memory can be toggled on or off in settings

This creates a feedback loop: the more you use Claude Code on a project, the better it understands your preferences and conventions, and the less you need to explain in each session.

Working with plans: structured thinking before coding

Plan Mode is one of the most powerful features for complex tasks. When you switch to Plan Mode (press Shift+Tab or /plan), Claude enters a read-only exploration state where it can read files, search code, and reason about architecture — but cannot modify anything.

When to use Plan Mode

• Large refactors — Before touching 20 files, have Claude map out the dependency graph and propose an order of operations
• Unfamiliar codebases — Let Claude explore and explain before you ask it to change things
• Architecture decisions — Have Claude evaluate trade-offs without committing to an implementation
• Debugging — Let Claude read logs, trace execution paths, and form hypotheses before applying fixes

Storing plans for future work

For long-running initiatives, you can ask Claude to write plans as markdown files in your repository. This is particularly useful for work that spans multiple sessions or involves multiple team members:

Create a plan for migrating from REST to GraphQL. Write it to docs/plans/graphql-migration.md.
Include: affected endpoints, proposed schema, migration order, rollback strategy, and estimated phases.

These plans become artefacts that the team can review, refine, and reference in future sessions. When you come back to continue the work, you can tell Claude to “read the migration plan in docs/plans/ and continue from phase 2.”

Background tasks and parallel work

For tasks that take time, press Ctrl+B to send them to the background. Claude pre-approves the necessary permissions and continues working while you do other things. You can run multiple background tasks concurrently — perfect for parallelising independent work streams.

Using Claude Code as a team

Claude Code becomes significantly more valuable when configured for team use. The key insight is that individual sessions are ephemeral, but team configuration is durable.

Shared configuration via git

Check these files into your repository to give every team member the same Claude Code experience:

File	Purpose
.claude/settings.json	Shared permission rules, hooks, and preferences
./CLAUDE.md	Project conventions, build commands, architecture docs
.claude/rules/	Modular, scoped instructions
.claude/agents/	Shared subagent definitions
.claude/skills/	Custom slash commands the team can use
.mcp.json	Shared MCP server connections

Personal overrides

Each developer can override shared settings with .claude/settings.local.json (gitignored) for personal preferences that should not affect the team — things like preferred model, personal MCP connections, or editor-specific hooks.

Organisation-wide policies

For enterprise teams, managed settings let administrators deploy organisation-wide policies:

• Enforce specific permission modes
• Control which models are available
• Set default CLAUDE.md instructions
• Deploy mandatory hooks (e.g., security scanning)

These are installed at the system level and take the highest precedence in the configuration hierarchy.

Team workflow patterns

Code review with Claude:

# Review a specific PR
claude --from-pr 142

# Review uncommitted changes
claude
> /review

Parallel feature development:

# Each developer works in an isolated worktree
claude --worktree feature-auth
claude --worktree feature-billing

Shared debugging context:

# Resume a named session a colleague started
claude --resume "investigate-memory-leak"

The implications of team adoption

When multiple developers use Claude Code on the same project, the shared CLAUDE.md becomes a living document that encodes team knowledge. Conventions that previously lived in people’s heads — “we always use UTC,” “never modify migration files directly,” “the billing service expects amounts in pence” — get written down once and enforced in every session.

This creates an interesting dynamic: Claude Code becomes a standardisation tool. New team members get the same quality guidance from day one. Code review disagreements about style disappear because the style is encoded in configuration. The team’s collective knowledge compounds in a way that survives individual contributors leaving.

Advanced techniques

Subagents for exploration

When you need to search broadly — “find all the places we handle authentication errors” — delegate to a subagent rather than doing it in your main conversation. Subagents get their own context window, so verbose search results do not pollute your primary session:

Use a subagent to find every file that imports from the auth module
and summarise how each one handles token expiry.

Non-interactive mode for automation

Claude Code works brilliantly in CI/CD pipelines and scripts:

# One-shot query with JSON output
claude -p "List all TODO comments in src/" --output-format json

# Pipe input for processing
git diff main | claude -p "Review this diff for security issues"

# Use in a pre-commit hook
claude -p "Check if any files in the staging area contain hardcoded secrets" --output-format text

Checkpointing and rewind

Every action Claude takes creates a checkpoint. If something goes wrong — a refactor breaks your tests, an edit goes in the wrong direction — press Esc Esc or use /rewind to roll back to any previous state. This restores both the conversation and file changes, making experimentation completely safe.

Context management

Context is the single most important constraint in Claude Code. The context window is large but finite, and a cluttered context produces worse output than a clean one. Best practices:

• Use /clear between unrelated tasks — do not let a debugging session’s context bleed into a feature implementation
• Use /compact when a session gets long — this compresses the conversation while preserving key information
• Delegate exploration to subagents — keep your main context focused on the task at hand
• Use --continue to resume rather than re-explaining context from scratch
• Name your sessions with /rename — makes them easy to find and resume later

Worktrees for parallel isolation

Git worktrees let you run multiple Claude Code instances on the same repository without file conflicts:

claude --worktree feature-auth

This creates an isolated copy of your repository on a separate branch. Each worktree has its own working directory, so Claude can edit files freely without affecting your main branch or other worktrees.

Global settings: configuring your environment

Your personal Claude Code environment lives in ~/.claude/. Here is what each file controls:

File	Purpose
~/.claude/settings.json	Personal permission rules, hooks, model preferences
~/.claude/CLAUDE.md	Personal instructions applied to all projects
~/.claude/keybindings.json	Custom keyboard shortcuts
~/.claude/agents/	Personal subagent definitions
~/.claude/rules/	Personal rule files
~/.claude.json	Preferences, OAuth tokens, MCP config

Recommended global settings

Here is a solid starting point for ~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Read(.env*)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)"
    ]
  },
  "model": "sonnet"
}

And a good personal ~/.claude/CLAUDE.md:

# Code Style

- Always read existing imports and conventions before editing a file
- Match the style already in use
- Declare imports at the top of the file

# Post-Change Review

- After significant changes, review for DRY violations
- Extract shared logic into functions to avoid duplication

IDE integrations

Claude Code integrates with your existing development environment:

VS Code

The official VS Code extension gives you a prompt box in the sidebar, file referencing with @, conversation management, and the ability to create commits and PRs without leaving the editor. It is the smoothest experience for developers who spend most of their time in VS Code.

JetBrains

IntelliJ, PyCharm, WebStorm, and the rest of the JetBrains family all have marketplace integrations. The experience is similar to VS Code, with support for remote development and WSL.

Terminal-first

Many power users prefer the raw terminal experience. Claude Code was designed terminal-first, and the CLI gives you the most control — especially for non-interactive mode, scripting, and CI/CD integration.

Common anti-patterns to avoid

Even experienced users fall into these traps:

1. Kitchen sink sessions — Mixing unrelated tasks in one conversation. Context gets muddled and output quality drops. Use /clear between tasks.

2. Correcting without restarting — If Claude is going down the wrong path, repeatedly correcting it pollutes the context with wrong approaches. Sometimes it is faster to /clear and restate the task cleanly.

3. Over-specified CLAUDE.md — A 500-line CLAUDE.md means Claude cannot prioritise which instructions matter most. Keep it under 200 lines and be ruthless about what earns a place there.

4. Trust without verification — Claude produces plausible-looking code. Always give it tests to run, type checking to pass, or other verification criteria. Plausible is not the same as correct.

5. Infinite exploration — Claude can explore a codebase forever. Scope your investigations: “find where we handle X in the auth module” not “find all the problems in the codebase.”

6. Ignoring the memory system — If you find yourself re-explaining the same things every session, you are not using CLAUDE.md or auto-memory effectively.

7. Not using Plan Mode — Jumping straight into code changes for complex tasks. The five minutes spent planning saves thirty minutes of rework.

Putting it all together

The developers who get the most out of Claude Code share a common approach: they invest in configuration upfront, they use the explore-plan-code-commit loop, they give Claude verification criteria, and they manage their context aggressively.

Start with /init to generate your CLAUDE.md. Set up your global settings with sensible permission rules. Learn the keyboard shortcuts. Use Plan Mode for anything non-trivial. And most importantly, iterate on your CLAUDE.md over time — it is a living document that should grow with your understanding of what works.

Claude Code is not a tool you learn once. It is a tool that learns with you.

---

Want help setting up Claude Code for your engineering team, or looking for guidance on AI-assisted development workflows? We work with teams across the UK to implement effective AI coding practices.

Get in touch — we would love to hear about what you are building.

Further reading

• Anthropic’s Claude Code documentation
• Model Context Protocol specification
• Claude Code GitHub repository

Back to Blog