@PawelHuryn: 187,000 people have starred one CLAUDE.md file on GitHub. A CLAUDE.md loads on every turn. Every line is rent you pay o…

X AI KOLs Timeline Tools
claude-md github ai-coding-assistant best-practices configuration

Summary

A Twitter thread by Paweł Huryn shares insights on writing effective CLAUDE.md files for Claude Code, emphasizing project-specific rules and avoiding unnecessary bloat.

187,000 people have starred one CLAUDE.md file on GitHub. A CLAUDE.md loads on every turn. Every line is rent you pay on every request. So look at what most of that file asks for. Match the existing style. Do only what was asked. Don't refactor code that works. Don't assume a library exists. None of that is advice. It's how Claude Code already behaves. Matching the existing style is even in its system prompt for Opus 4.8. The rules worth the rent are specific to your project. Often earned from a mistake. Examples: - Version bumps are user-initiated - There are three kinds of tests, and it matters which is which: npm test, CI tests, npm run test:live (...) - Don't skip the tag/release (or the vsix asset) on a release push - Sign GitHub comments (...) Written with an agent, reviewed by Paweł (...) Written by Paweł's agent A line copied from GitHub is a guess about a problem you might have. A line you wrote after the third time something broke is policy. Everything else loads on demand. The main file stays short, and Claude reads database.md or security.md or cron.md only when the task needs them. That's the setup you can't star.
Original Article
View Cached Full Text

Cached at: 07/04/26, 08:42 AM

187,000 people have starred one CLAUDE.md file on GitHub.

A CLAUDE.md loads on every turn. Every line is rent you pay on every request.

So look at what most of that file asks for. Match the existing style. Do only what was asked. Don’t refactor code that works. Don’t assume a library exists. None of that is advice. It’s how Claude Code already behaves. Matching the existing style is even in its system prompt for Opus 4.8.

The rules worth the rent are specific to your project. Often earned from a mistake. Examples:

  • Version bumps are user-initiated
  • There are three kinds of tests, and it matters which is which: npm test, CI tests, npm run test:live (…)
  • Don’t skip the tag/release (or the vsix asset) on a release push
  • Sign GitHub comments (…) Written with an agent, reviewed by Paweł (…) Written by Paweł’s agent

A line copied from GitHub is a guess about a problem you might have. A line you wrote after the third time something broke is policy.

Everything else loads on demand. The main file stays short, and Claude reads database.md or security.md or cron.md only when the task needs them.

That’s the setup you can’t star.

Similar Articles