… has too many hobbies.

Streamlining my user-level CLAUDE.md

I've recently streamlined my ~/.claude/CLAUDE.md based on:

  • Informal observations about what Claude does and doesn't do well
  • A desire to avoid conflicting with principles that seem to be built into Claude Code these days, e.g. planning mode
  • Informal observations about the workflows I tend to use with Claude Code
  • A desire to simplify it and therefore more closely align with e.g. Claude Code on the web

It now mainly contains guidelines that Claude should abide by while using its own planning and decision-making tools (or referring decisions to me).

The complete, updated CLAUDE.md:

# Development Guidelines

## Philosophy

### Core Beliefs

- **Incremental progress over big bangs** - Small changes that compile and pass tests
- **Learning from existing code** - Study and plan before implementing
- **Pragmatic over dogmatic** - Adapt to project reality
- **Clear intent over clever code** - Be boring and obvious

### Simplicity

- **Single responsibility** per function/class
- **Avoid premature abstractions**
- **No clever tricks** - choose the boring solution
- If you need to explain it, it's too complex

## Technical Standards

### Architecture Principles

- **Composition over inheritance** - Use dependency injection
- **Interfaces over singletons** - Enable testing and flexibility
- **Explicit over implicit** - Clear data flow and dependencies
- **Test-driven when possible** - Never disable tests, fix them

### Error Handling

- **Fail fast** with descriptive messages
- **Include context** for debugging
- **Handle errors** at appropriate level
- **Never** silently swallow exceptions

## Project Integration

### Learn the Codebase

- Find similar features/components
- Identify common patterns and conventions
- Use same libraries/utilities when possible
- Follow existing test patterns

### Tooling

- Use project's existing build system
- Use project's existing test framework
- Use project's formatter/linter settings
- Don't introduce new tools without strong justification

### Code Style

- Follow existing conventions in the project
- Refer to linter configurations and .editorconfig, if present
- Text files should always end with an empty line

## MCP Tool Use

- Use Context7 to validate current documentation about software libraries
- Use searxng if your primary Web Search or Fetch tools fail
- Use Tavily ONLY when searxng doesn't give you enough information

## Important Reminders

**NEVER**:
- Use `--no-verify` to bypass commit hooks
- Disable tests instead of fixing them
- Commit code that doesn't compile
- Make assumptions - verify with existing code

**ALWAYS**:
- Commit working code incrementally
- Update plan documentation as you go
- Learn from existing implementations
- Stop after 3 failed attempts and reassess