Ask the user about their preferences Only ask what cannot be inferred. Ask in a single grouped message:

Philosophy (most important):
- "What are your core engineering values? The principles that guide your decisions when there's no clear right answer."
- Prompt with contrasting examples to help them articulate:
  - "YAGNI vs. building for extensibility?"
  - "Simplicity vs. performance?"
  - "Explicit vs. DRY?"
- Target: 3-5 bullet points that are OPINIONATED and SPECIFIC
- Quality test: "Would two reasonable engineers disagree on this?" — if no, it's too generic
Preferences:
- Preferred response language
- Primary language/framework (TypeScript, Python, Go, etc.)
- Package manager preference (pnpm, npm, yarn, bun, uv, etc.)
- Test runner preference (vitest, jest, pytest, etc.)
- Commit convention (conventional commits, other)
Think before writing (critical step) Before generating, evaluate each candidate line against the golden rule:
- "Can the agent discover this on its own?" → if YES, don't include
- "Is this a generic best practice any senior dev knows?" → if YES, don't include
- "Would the agent make the WRONG choice without this?" → if YES, include
Generate the file following these principles

The golden rule: write only what the agent cannot discover on its own.

Include ONLY these sections:

Philosophy (~4 lines)
- The user's core engineering values from step 2
- These shape HOW the agent thinks — they're the tiebreakers for ambiguous decisions
Response language & style (~2 lines)
- Language to respond in
- Communication style (e.g., no unsolicited explanations)
Code conventions (~4 lines)
- Naming conventions (files, variables, components, constants)
- Strictness rules (e.g., strict TypeScript, unknown over any)
- Only conventions the agent would get wrong without guidance
Tools (~3 lines)
- Package manager
- Test runner
- "Run tests after changes" if that's the user's expectation
Git (~3 lines)
- Commit message format
- Key guardrails (no force push, no amend published commits)
Workflow (~3 lines)
- Critical process rules (read before edit, one task at a time)
- Only rules the agent tends to violate
Review and trim (critical step) Read the generated file as if you're paying per token (because the user is). For each line, ask these 3 questions: a) "Would the agent get this wrong without this line?" → if NO, delete b) "Is this already enforced by a linter, type system, or config?" → if YES, delete c) "Can I merge this with another line without losing meaning?" → if YES, merge

Then verify:
- Line count within target (~30 lines, 25-35 acceptable)
- No two lines say the same thing differently
- Every bullet is a COMMAND or CONSTRAINT, not a description
Write the file
- Write to ~/.claude/CLAUDE.md
- Use # headers for sections (no nested headers)
- Use - bullet lists, no numbered lists
- No XML tags, no code blocks, no frontmatter — plain markdown only

# Philosophy
- YAGNI: only implement what's needed NOW — no speculative abstractions
- Explicit over DRY: a little repetition is better than the wrong abstraction
- Fix root causes, never band-aid solutions

# Language
Always respond in French. Code and commits in English.

# Code conventions
- Files: kebab-case | Variables: camelCase | Components: PascalCase
- Strict TypeScript: prefer unknown over any, no implicit returns

# Tools
- Package manager: pnpm
- Tests: vitest — run after every change

# Git
- Conventional commits: feat(scope): msg, fix:, refactor:, chore:
- Never force push to main

# Workflow
- Read files before editing — understand context first
- One task at a time: finish and verify before starting the next

BAD — verbose, generic, full of things the agent already knows (annotated):

# About Me                                    ← REMOVE: not actionable
I am a senior software engineer who values    ← REMOVE: narrative, not instruction
clean code and best practices.                ← REMOVE: generic, no one disagrees

# Code Style
- Use meaningful variable names               ← REMOVE: generic best practice
- Write clean, maintainable code              ← REMOVE: generic, adds nothing
- Use async/await for asynchronous operations ← REMOVE: agent already knows
- Handle errors with try/catch                ← REMOVE: agent already knows
- Import modules at the top of the file       ← REMOVE: agent already knows
- Files: kebab-case                           ← KEEP: naming convention
- Variables: camelCase                        ← MERGE: combine with above
- Components: PascalCase                      ← MERGE: combine with above

# Project Structure                           ← REMOVE: entire section
src/                                          ← REMOVE: agent runs ls
├── components/                               ← REMOVE: agent runs ls
├── utils/                                    ← REMOVE: agent runs ls
└── lib/                                      ← REMOVE: agent runs ls

# Tools
- Package manager: pnpm                       ← KEEP: preference
- Always run npm install before starting      ← REMOVE: contradicts pnpm above
- Use prettier for formatting                 ← REMOVE: agent reads config

claude-md-global

claude-md-global

More from reizam/claude-md-templates

claude-md-project

claude-md-audit