CLAUDE.md as team contract
Read the field note below to see how we apply this pattern in real Claude Code projects.
F3: CLAUDE.md as team contract
Once more than one person relies on CLAUDE.md, it stops being notes and starts being a contract. Treat it as personal scratchpad and you get three engineers effectively working under three different rulebooks. Treat it as code, with versioning, review, and ownership, and the file becomes the cheapest alignment tool on the team.
What we tried
We stopped tolerating divergent local copies. CLAUDE.md (and every child CLAUDE.md) moved into the PR review cycle. No silent edits, no local overrides, no "I'll commit this later". The rules became:
- Versioned. Changes ship in PRs and are attributed like any other code.
- Reviewed. At least one reviewer signs off on the diff, same as a code change.
- Owned. Each file has an owner listed in CODEOWNERS. The owner is the person a reviewer pings when a rule feels wrong.
How the contract stays a contract
The loop only works if updating CLAUDE.md is treated as part of finishing the decision, not as documentation to write later. Skipping that step is how drift starts.
What happened
Volume of "how do we handle X" messages in Slack dropped quickly, from several per week to about one or two per sprint. PR approvals got faster because reviewers could point to a line in the contract instead of re-litigating style in the comments. New engineers stopped needing a buddy to interpret the repo; the file did that work.
What we learned
CLAUDE.mdshould be reviewed, versioned, and owned like any production artifact.- Keep policy explicit: what to do, what not to do, and why. The "why" is the part that survives contact with new contributors.
- A living contract beats a long static handbook. The file is useful precisely because it stays current.
Result
The Slack volume drop was the headline. The quieter win was review quality: comments shifted from style nits to actual design questions, because the style decisions had already been made and were linkable. The cost is real discipline: the file has to be updated when decisions change, and that is easy to skip under deadline pressure. We have let it fall two or three sprints behind reality before someone flagged it. The contract only works if the team treats updating it as part of finishing a decision.
Quick answers
What do I get from this cable?
You get a dated field note that explains how we handle this team-setup workflow in real Claude Code projects.
How much time should I budget?
Typical effort is 12 min. The cable is marked intermediate.
How do I install the artifact?
This cable is guidance-only and does not ship an installable artifact.
How fresh is the guidance?
The cable is explicitly last verified on 2026-04-15, and includes source links for traceability.
Work with FRE|Nxt
We build the production AI systems we write about.
Cables are the field notes. The playbooks come from client engagements — multi-agent systems, RAG pipelines, and LLM cost cuts that ship and hold up in production. If something here maps to a problem on your roadmap, two ways in:
Audit capacity: 5 slots/month · No pitch deck · NDA on request
Your LLM cannot read your agent state
The most common architectural mistake when building LangGraph agents is assuming the LLM can see your state fields. It cannot. The LLM only sees three things…
Prompt caching kills dynamic injection. Pick one
Building a production LangGraph agent requires middleware that injects dynamic content into the system prompt every turn. Prompt caching requires that the sy…
Sub-agents are the same agent, smaller
When you add sub-agents to a production LangGraph system, the instinct is to build them as a separate agent type with its own state schema, its own graph str…