Testing

💡CLAUDE[.]md Tips & Tricks (Cheatsheet)

CLAUDE[.]md is one of the most important files in any Claude Code project. Think of it as project memory + execution guidelines.

It tells Claude what your project is, how the codebase is structured, what design rules to follow, and what patterns to avoid.

Here are 8 practical tips for writing a better CLAUDE[.]md:

1⃣ Know the difference between project and global CLAUDE.md

A project-based CLAUDE[.]md lives in your project root and is specific to that product.
A global CLAUDE[.]md lives in your Claude env and defines reusable preferences across all projects.

Project CLAUDE.md = project context
Global CLAUDE.md = personal working style

2⃣ Structure it properly

Claude performs better when information is grouped semantically.
Thats why don’t write random instructions.

Use clear sections like:
✅ Project Overview
✅ Tech Stack
✅ Folder Structure
✅ UI/UX Principles
✅ Component Rules
✅ Accessibility Requirements
✅ Testing Strategy
✅ Content Guidelines
✅ Deployment Notes

3⃣ Use [/]init to create the first draft

You don’t need to start from a blank page.
Run [/]init so Claude Code will scan your project and generate a first version of CLAUDE[.]md
It won’t be perfect, but it gives you a solid starting point.

4⃣ Keep it short

CLAUDE[.]md is loaded into every Claude Code session, so it consumes context.

My rule of thumb: Keep it under 200 lines.
Ideally, under 100.

For detailed documentation, use routing rules

5⃣ Be specific

Bad instruction: “Write clean code.”
Better instruction: “Use descriptive prop names, no abbreviations” and “Prefer composition over inheritance.”

The more precise your instructions are, the more deterministic Claude’s output becomes.

6⃣ Treat CLAUDE.md as a living document

Don’t create it once and forget it.

Update it when:
✅ Claude repeats the same mistake
✅ You introduce a new pattern
✅ Your product requirements change
✅ Your design system evolves
✅ Your team agrees on new rules

The best CLAUDE.md files are built from real usage, not theory.

7⃣Use [.]claude/rules for modular instructions

Instead of putting everything into one file, split rules by topic and then reference them from CLAUDE[.]md or directly in Claude Code chat.

This creates cleaner, more focused context.

8⃣ Commit CLAUDE[.]md to Git

Your project-based CLAUDE.md is part of your project infrastructure.

When you commit it to Git, the whole team gets more consistent AI behavior.

Complete guide 👇

My fav way to un-slop a codebase:

- find large files
- ask to break up, improve code quality, add tests
Once done, ask "now that you read the code, what can we improve?"
- store that in a tracker file (i use docs/refactor/*.md) and let the model pick
- do one by one

Claude Code tips that have made my life easier:

(Add these to your CLAUDE .md file)

1. "Before writing any code, describe your approach and wait for approval. Always ask clarifying questions before writing any code if requirements are ambiguous."

2. "If a task requires changes to more than 3 files, stop and break it into smaller tasks first."

3. "After writing code, list what could break and suggest tests to cover it."

4. "When there’s a bug, start by writing a test that reproduces it, then fix it until the test passes."

5. "Every time I correct you, add a new rule to the CLAUDE .md file so it never happens again."

The wording in the file is much more detailed than what I wrote above, but hopefully these show the spirit.