CLAUDE.md Rules for Claude Code That You Can Check

A developer from BetterToken outlined best practices for writing CLAUDE.md project rules that make Claude Code predictable, emphasizing observable checks, short contracts, and clear boundaries. The guidance covers structuring rules with goals, boundaries, and reproducible commands, avoiding secrets in the file, and resolving conflicts between root and package-specific rules. The post also references BetterToken's API access for Claude Code integration.

A long list of preferences does not make Claude Code predictable. A useful project rule says what the agent may do, what it must avoid, and which command or diff proves the result. Put architecture notes in docs/ ; keep the project contract short. Project rules Goal - Keep changes limited to the requested feature. Before editing - Read package.json and the files named in the task. - Do not read or print .env files. Checks - Run npm test after code changes. - Run npm run lint when TypeScript files change. - Report each command, its exit code, and every changed file path. Scope and conflicts - Rules in packages/payments/CLAUDE.md apply only under packages/payments/ . - Inside that directory, the local rule wins when it directly conflicts with this root file. - Root security and secret-handling rules always apply. Forbidden - Do not run deploy, publish, or destructive Git commands. Each line has an observable result. “Write quality code” does not; “run npm test and report its exit code” does. Use a goal for the requested outcome, a boundary for files or commands that are off limits, a check for a reproducible command, and a style rule only when it affects review. If a command is not present in package.json , do not invent it. Move long explanations and exception lists to documentation with a link from CLAUDE.md . CLAUDE.md is part of the repository and is read with the project. Never put API keys, CI tokens, real personal data, or copied API responses in it. State the boundary instead: - Never open, print, or commit .env , .pem , or secrets/ . - Use API KEY=your api key here in examples. Pass a real key through an environment or secret store when a test needs one. Do not paste it into a prompt or handoff. Keep repository-wide rules in the root file and package-specific rules close to the package. When two files disagree, inspect the instructions visible to the target file, remove the duplicate, and keep the narrower rule local. Do not add another paragraph to hide a conflict. Test one rule with a reversible task: git diff --check and inspect git diff --stat . CLAUDE.md .For Claude Code API work, use your own key and check the current Base URL and model in BetterToken’s Claude Code documentation https://docs.bettertoken.ai/ai-tools/claude-code?utm source=devto&utm medium=syndication&utm campaign=SEO-100&utm content=claude-md-rules-for-coding-agent . BetterToken provides API access and usage data; it does not turn CLAUDE.md into a secret store or replace Claude Code settings. Originally published on the BetterToken blog. BetterToken provides pay-as-you-go access to AI model APIs through OpenAI-compatible and Anthropic-compatible endpoints — useful if you are wiring Claude Code, Codex, or your own tooling to a custom base URL. See the docs https://docs.bettertoken.ai/?utm source=devto&utm medium=syndication&utm campaign=SEO-100&utm content=claude-md-rules-for-claude-code to get started.