How repository rules should work across coding agents

Write rules for the repository, not one vendor

The durable source should describe how the codebase works; adapters can translate that source for each agent.

Teams increasingly use several coding agents. If every important convention lives only in one editor’s settings, the same repository develops different standards depending on who opened it. AGENTS.md, CLAUDE.md, Cursor rules, docs, tests, and ownership files already contain useful pieces of the contract.

Brief scans those sources and presents the relevant slice through MCP. Developers can keep using Cursor, Codex, Claude Code, or another compatible agent while Brief applies the same repository evidence to context and review.

A good rule changes a decision

Keep commands, boundaries, and canonical examples; remove generic advice the agent already knows.

“Write clean code” does not tell an agent what to do. “API routes live under app/api and use requireWorkspacePermission before reading tenant data” changes both file placement and implementation. “Run tests” is weak; naming the focused command and the test file pattern is actionable.

Rules also need maintenance. Pointing to a canonical component is usually safer than copying its entire implementation into a markdown file. When the component changes, the reference remains current. Brief’s packets cite the source, so a stale instruction can be traced and corrected.

• Name the decision or boundary the rule controls
• Scope it to a directory, component, or risk when possible
• Link to the canonical implementation instead of duplicating it
• Include the exact check that proves compliance
• Record an owner for rules that can block work

Separate team policy from personal preference

Preferences can add helpful defaults, but they must not relax a higher-authority requirement.

A developer may prefer concise comments or a particular test style. A security owner may require tenant checks on every workspace route. Treating those statements as equivalent creates conflicts that the agent cannot resolve safely.

Brief’s team context can promote approved rules and review memories. Personal forks remain useful for individual workflows, but the merge order preserves mandatory team policy. Findings remain advisory until a rule is deterministic or an owner has approved enforcement.

Grow the rule set from real review evidence

Add a rule when the same consequential mistake repeats—not for every comment ever written.

Large rule catalogs become another source of noise. A better loop starts with a real review finding, captures the lesson, checks whether it generalizes, and lets a maintainer approve it for the right scope. The next context packet can then surface it before the mistake repeats.

This keeps the repository contract grounded in work the team has actually seen. It also gives rules a retirement path: if the underlying architecture changes, the source and owner are visible instead of buried in an old prompt.