People ask to see my Claude Code configuration more than any other request I get. Here it is, every file, every setting, with explanations for why I chose each option.

The CLAUDE.md System

I use a layered system of CLAUDE.md files. There's a global one that applies to every project and a project-specific one in each repository.

Global CLAUDE.md (in ~/.claude/CLAUDE.md):

# Global Rules
- Read relevant files before making changes
- Run tests after modifications when a test suite exists
- Never apologize or add unnecessary comments
- Prefer simple solutions with minimal abstractions
- When uncertain about intent, ask instead of guessing
- Use existing project patterns rather than introducing new ones
- Keep functions under 40 lines
- Every new function needs at least one test

This global file handles the 80% of instructions that are the same across all projects. The key insight: these aren't style preferences. They're behavioral constraints that reduce errors. "Read relevant files before making changes" alone prevents about half of all wrong suggestions.

Project-specific CLAUDE.md example:

# Project: API Service
Stack: Node.js, TypeScript, Express, Prisma, PostgreSQL

# Directory Structure
src/routes/ - Express route handlers (thin, validation only)
src/services/ - Business logic (all logic lives here)
src/models/ - Prisma schema and generated types
src/middleware/ - Auth, logging, error handling
src/utils/ - Shared utilities
tests/ - Jest tests, mirrors src/ structure

# Patterns
- Route handlers parse input, call service, format response
- Services throw AppError with status code and message
- All database access goes through Prisma, no raw SQL
- Environment config in src/config.ts, never process.env directly
- Dates stored as UTC, converted at the API boundary

# Don't
- Don't add new dependencies without asking
- Don't modify migration files
- Don't use any types unless truly necessary
- Don't put business logic in route handlers

The "Don't" section is just as important as the positive instructions. Without it, Claude will occasionally add a convenient npm package or slip logic into a route handler because "it's simpler."

MCP Servers

My .claude/settings.json configures three MCP servers:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://localhost:5432/myapp_dev"],
      "env": {}
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "..." }
    },
    "docs": {
      "command": "node",
      "args": ["./tools/mcp-docs-server/index.js"],
      "env": {}
    }
  }
}

The Postgres server is read-only for the dev database. Claude can check schemas, verify data shapes, and understand relationships without me pasting SQL. The GitHub server lets Claude read issues and PRs directly. The docs server is a custom 80-line Node script that serves our internal API documentation and architecture decision records.

Custom Slash Commands

I keep a .claude/commands/ directory with custom slash commands that I use daily:

/review - Runs a pre-PR code review:

Review all staged changes for:
1. Security issues (injection, auth bypass, data exposure)
2. Bugs and logic errors
3. Missing error handling
4. Performance problems
5. Breaking changes to existing APIs
Reference specific files and lines. Skip style issues.

/test - Generates tests for a module:

Read $ARGUMENTS and write comprehensive tests.
Follow the existing test patterns in the tests/ directory.
Cover: happy path, edge cases, error conditions.
Each test name describes the scenario being tested.
Run the tests after writing them.

/explain - Deep code explanation:

Read $ARGUMENTS thoroughly. Explain:
1. What it does (one paragraph)
2. How the data flows through it
3. What depends on it and what it depends on
4. Any non-obvious behavior or gotchas

Slash commands are underused by most Claude Code users. They turn multi-line prompts into single commands. I've saved the most time by making the actions I repeat daily into one-word triggers.

Permission Settings

I run Claude Code with these permission constraints:

  • File edits: Allowed in project directory only
  • Shell commands: Allowed for npm test, npm run lint, git status, git diff. Everything else requires approval.
  • Network access: Disabled except through MCP servers

I've seen people run Claude Code with full permissions. That's fine for personal projects. For anything with production credentials, API keys, or sensitive data in the environment, lock it down. Claude Code will ask permission for restricted actions, and saying "yes" is easier than recovering from a mistake.

Workflow Integration

My terminal layout for a typical Claude Code session:

  • Left pane: Claude Code session
  • Right top: VS Code with the project open (for reviewing diffs)
  • Right bottom: Terminal with test watcher running

When Claude makes changes, I see the diff in VS Code immediately and the test results update automatically. This three-panel setup gives me a tight feedback loop without switching between applications.

The One Setting That Matters Most

If you only do one thing from this post, write a good CLAUDE.md for your project. Specific directory structure, explicit patterns, clear constraints. Everything else is optimization. The CLAUDE.md is the foundation. A well-written project context file does more for output quality than any amount of clever prompting.