.cursor/rules, CLAUDE.md aren't decision memory

Project rule files are useful, and Git makes them versionable. The problem begins when two agents, projects or teams each have an accurate-looking copy of a rule but no shared answer to why it exists, who approved it, where it applies and whether it was replaced.

Cursor’s Project Rules live in .cursor/rules and can be committed to a repository. Claude Code’s CLAUDE.md instructions can likewise be stored with a project. AGENTS.md can also be version-controlled. These files are legitimate ways to guide agents; they are not inherently unversioned, unowned or ineffective.

Where Git-backed instructions work well

For one repository and one team, a reviewed rule file can be enough. The repo already has a workflow for pull requests and code review. Cursor can apply rules based on scope, while Claude Code can use project instructions. Keep tool-specific syntax in the tools that understand it.

The difficulty is not whether Git can record changes. It is whether the same decision stays current across every place that consumes it.

Two practical ways project instructions drift

Example 1 — a security rule exists in one agent’s context. A team decides that customer identifiers must never enter application logs. The Cursor project rule is updated and reviewed, but the Claude instructions used by another repository still contain the old diagnostic-logging example. Both files have a valid Git history. Neither history alone tells the second agent that a newer, organization-wide decision applies to its current task.

Example 2 — an architecture exception outlives its approval. A team temporarily permits a direct database call during migration, scoped to one service until the end of the quarter. Months later, a copied rule still mentions the exception with no expiry or superseding decision. The next agent follows the file faithfully, even though the team has returned to the repository abstraction.

Neither scenario requires discarding native rule files. It requires recording the underlying decision, its owner, scope, effective status and replacement history.

Native instruction files and a shared decision process

A workflow that preserves what the team decided

1. Keep the rule files. Review them through normal repository pull requests. Identify which entries are coding style, which are temporary task notes and which trace back to consequential decisions.
2. Capture the reason and authority. For one important rule, record its rationale, approved status, owner, affected services, exceptions and how an earlier decision is superseded.
3. Prepare only relevant context. When a supported MCP client is explicitly connected, DM can return the approved Rules, Skills and Decisions that apply to the work. It does not execute or independently police the coding agent.
4. Return new observations for review. If the task uncovers an exception or proposes a new mini-decision, submit structured learning where supported. A human decides whether it becomes trusted shared context.
5. Maintain native instructions deliberately. A team may still update .cursor/rules or CLAUDE.md in Git, but those files should reflect the current approved decision rather than become an accidental second authority.

The distinction is between versioning a file and maintaining an applicable decision across people and tools. A team with one stable repository may need only its Git-backed instructions. A team whose agents work across several projects can benefit from an explicit shared approval and applicability process.

Explore the coding-agent alignment workflow for a representative context-in, structured-learning-back example, or request early access if coordinating agents across projects is already a recurring problem.