Every team using an AI coding assistant ends up with some form of repo-level instruction file: the CLAUDE.md file for Claude Code, .cursor/rules/*.mdc for Cursor, or a plain AGENTS.md that both of those and a growing list of other tools can read. The question that took longest to settle wasn't what to write in it, it was what to do with it in version control.

What to commit

Commit the instruction file itself, at the root of the repository, so every clone starts from the same conventions. Six months in, the team that treated it as reviewable documentation (pull requests, diffs, a changelog entry when a convention changed) kept it accurate. The team that let each developer maintain a private copy ended up with three incompatible versions of "how we do commits here" within a quarter.

Which specific file depends on the tool, and it's worth getting current on this rather than assuming last year's convention still holds. Cursor's own documentation no longer mentions the single .cursorrules file at all; Project Rules now live as .mdc files under .cursor/rules/, with frontmatter metadata, and Cursor reads a plain AGENTS.md directly too if you'd rather keep one file across tools instead of a Cursor-specific format. AGENTS.md itself is the more tool-neutral option: an open, plain-markdown standard that OpenAI Codex, Cursor, GitHub Copilot, and a long list of other agents and editors already support, with no required fields and no vendor-specific syntax to maintain.

What to gitignore

Anything generated during a single working session and not meant to outlive it: scratch files, intermediate plans, per-run logs. These are the AI-assistant equivalent of build artifacts, useful while you're looking at them, noise in a diff six months later.

What drifts fastest

The section that goes stale first is almost always the one listing which commands are safe to run without asking first. CI configuration and tooling change more often than architecture does, and a stale allowlist either blocks harmless commands or, worse, quietly permits ones that used to be safe and no longer are. Review that section on the same cadence as your CI config, not once at project setup and never again.