Most teams write a CLAUDE.md that lists their lint rules and a one-line project description. That is a config file. It misses the actual mechanism.
The file loads automatically at the start of every Claude session. That single property makes it the highest-leverage piece of persistent context in the entire workflow. Every conversation that does not start with the file ends up retyping the same context — who owns what, this quarter's priorities, the V1 API we already decided to deprecate. Each retype is coordination tax. The tax compounds across every engineer and every session.
Reframe it: CLAUDE.md is the operating system for how your team works with Claude. Not a README. Not a config file. A living document that encodes how the org thinks, decides, and communicates — loaded into every session by default.
One constraint, named upfront: the value of this system tracks the honesty of the maintenance. A CLAUDE.md full of priorities the team has quietly abandoned produces confidently misaligned advice — worse than no file at all. The weekly update ritual is not optional. It is what keeps the rest from rotting.
Generic Assistant vs. One That Knows Your Org
The gap is not model quality. It is what the model was given to start with.
Open a Claude session without organizational context and you start at zero. The model does not know your team lead is on parental leave, that your infra budget got cut 30% last month, or that the board approved an enterprise pivot last Tuesday.
Those facts shape every recommendation. Without them, the answers are technically sound and organizationally tone-deaf. With them, you get a collaborator that understands the constraints, respects ownership boundaries, and stays inside what the team already committed to.
Practitioner reports converge on roughly 40-60% less time spent on session-setup prompts when persistent org context is loaded — though the spread is wide and depends on team size and workflow shape.[2] The bigger gain shows up downstream: outputs need fewer correction cycles because the model is no longer guessing at the org topology.
Seven Sections That Turn a Config File Into Institutional Memory
Each section closes a specific gap the model cannot infer from your code.
A useful organizational CLAUDE.md covers seven areas. Few teams need all seven on day one — start with two or three and expand as the gaps surface. The constraint is simple: capture context Claude cannot infer from the code but that shapes every decision.
- [01]
Team Topology and Ownership Map
Teams, leads, what they own. Reporting lines if they affect routing. When Claude proposes a change to a service, it should know which team to tag for review and whose roadmap absorbs the impact. Without this, every suggestion routes to the same default reviewer regardless of ownership.
- [02]
Engineering Manager Scope and Strengths
For each EM, document scope (reports, services owned) and known strengths. If the infra EM has deep Kubernetes expertise, the model should weight that when proposing migration paths. The output gets sharper because the constraint is named.
- [03]
Strategic Priorities (Quarterly)
The current quarter's top 3-5 priorities with one-line rationale each. This is the section that prevents Claude from suggesting work that conflicts with what leadership already committed to. Without it, you get plausible suggestions that the org has already ruled out.
- [04]
Escalation Paths
When and how to escalate. On-call rotation. Severity definitions. Final decision authority on cross-team disputes. Documented escalation prevents the failure mode where every borderline incident routes to whoever is most senior in Slack at 2am.
- [05]
Communication Norms
Spell out how the team works: async-first with Slack threads, synchronous standups, RFC-driven decisions, or some combination. Claude should draft communications that match the team's actual mode. The output that fits the channel ships. The output that does not gets rewritten.
- [06]
Active Experiments and Bets
Feature flags, A/B tests, architectural spikes currently running. The model should know not to touch code behind an active experiment without explicit approval. The blast radius of a stray refactor inside a live test is real and avoidable.
- [07]
Decision Register
A running log of consequential decisions: date, participants, reasoning. This is the highest-leverage section in the file. It stops Claude from relitigating settled debates and gives the model the 'why' behind your architecture. Without it, the same trade-off gets re-argued every quarter as people roll on and off the team.
CLAUDE.md# Acme Corp — Engineering Context
@teams.md
@priorities-q1-2026.md
@decisions.md
## Active Priorities (Q1 2026)
- Migrate payment service to Stripe v4 (owner: @payments-team, deadline: Mar 31)
- Reduce P95 latency on /api/search below 200ms (owner: @platform)
- Ship enterprise SSO — signed contracts depend on April delivery
## Communication Norms
- Async-first. Default to Slack threads, not DMs.
- RFCs required for changes touching 3+ services.
- On-call escalation: #incidents channel, then PagerDuty.
## Decision Register (Recent)
- 2026-01-15: Chose PostgreSQL over DynamoDB for audit logs. Rationale: team expertise, join queries needed. Participants: @alice, @bob.
- 2026-02-03: Rejected microservice split for billing. Monolith stays until payment migration completes. Participants: @carol, @dave.
## Off-Limits
- Do NOT modify feature-flag configs in `config/experiments/` without explicit approval.
- Legacy `/v1/` API routes are frozen — deprecation scheduled for Q2.CLAUDE.md, Skills, MCP: Three Layers, Different Failure Modes
Stuff everything in one layer and the system breaks in predictable ways. Distribute it correctly and each layer pays for itself.
| Layer | Purpose | When to Use | Token Cost | Example |
|---|---|---|---|---|
| CLAUDE.md | Declarative knowledge — what and why | Facts the model needs every time | Loaded every session | Team topology, quarterly priorities, decision log |
| Skills | Procedural knowledge — how | Multi-step workflows triggered on demand | 30-50 tokens idle; full load on trigger | /deploy, /update-context, /write-rfc |
| MCP Servers | External connectivity — live data | Real-time data from tools and databases | ~55K tokens for 5 servers + 58 tools | GitHub PRs, Jira tickets, Slack messages |
The most common failure is stuffing every fact into CLAUDE.md. A 500-line file dilutes signal with noise — the section the model actually needs gets buried. Working ceiling: roughly 50-100 lines in the root file, with @imports pulling in detailed sections only when relevant. Calibrate against what your team actually consults. Sub-directory CLAUDE.md files let each team carry their own context without bloating the global surface.
Skills sit in the right layer for recurring procedures. Deployment checklist, incident response playbook, RFC template — procedural, not declarative. As Skills they cost effectively nothing until invoked, then load full instructions just-in-time.[5]
MCP closes the live-data gap. CLAUDE.md can say 'we use Linear for project tracking' but it cannot show the current sprint board. An MCP server[7] for Linear bridges that — real-time access without pasting ticket details into every conversation.
The Maintenance Ritual: /update-context Keeps the OS From Rotting
Static documentation decays. The fix is not discipline. The fix is a structured weekly mechanism.
Static documentation rots. That is the failure mode every persistent context system inherits — the org moves on while the file sits unchanged. Untracked drift turns the OS into a confidently misaligned advisor.
The /update-context skill closes this loop. Once a week, you run it. The skill prompts Claude to scan recent changes across the codebase, the decision log, and team communications, then proposes specific amendments to your CLAUDE.md files. You review, approve or modify, and the org context stays current. Maintenance becomes a structured conversation instead of a chore that nobody owns.
- [01]
Create the skill file in your commands directory
bashmkdir -p .claude/commands touch .claude/commands/update-context.md - [02]
Define the skill frontmatter and instructions
markdown--- description: Review recent changes and propose CLAUDE.md amendments --- You are updating the organizational context in CLAUDE.md. ## Steps 1. Read the current CLAUDE.md and all @imported files 2. Check git log for the past 7 days: `git log --since="7 days ago" --oneline` 3. Identify changes that affect team structure, priorities, or decisions 4. Review any new or modified ADRs in `docs/decisions/` 5. Propose specific amendments as a diff — additions, removals, edits 6. Halt and wait for human approval before writing changes ## Rules - Never remove decision register entries — only add new ones - Flag any priority that shows no commits in the past 14 days as stale - Keep the root CLAUDE.md under 100 lines — propose @imports for overflow - [03]
Schedule the weekly trigger via task runner or calendar reminder
bash# Wire into Monday standup or CI schedule # Option A: manual trigger claude /update-context # Option B: GitHub Actions cron (Monday 9am UTC) # See workflow example below
.github/workflows/update-context.ymlname: Weekly Context Update
on:
schedule:
- cron: '0 9 * * 1' # Monday 9am UTC
workflow_dispatch:
jobs:
update-context:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: anthropics/claude-code-action@v1
with:
prompt: /update-context
allowed_tools: read,write,bash
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}Hierarchical Context: Local Autonomy, Global Standards
Nested CLAUDE.md files give each team their own context surface without forcing a re-vote on what's already settled at the root.
CLAUDE.md Hierarchy for a Multi-Team Org
treemonorepo/
├── CLAUDE.md
│ └── # Global: org priorities, escalation paths, communication norms
├── teams.md
│ └── # @imported: full team roster and ownership map
├── decisions.md
│ └── # @imported: organization-wide decision register
└── services/
├── payments/
│ └── CLAUDE.md
│ └── # Payments team context: Stripe migration status, PCI compliance rules
├── platform/
│ └── CLAUDE.md
│ └── # Platform team context: latency targets, infrastructure constraints
└── frontend/
└── CLAUDE.md
└── # Frontend team context: design system version, browser support matrixClaude loads CLAUDE.md files hierarchically. Working in services/payments/ means the model sees both the root org context and the payments-specific context. Each team carries their own file without duplicating global information.
The leverage: the payments team documents Stripe-specific conventions, PCI compliance constraints, and migration timeline without polluting the file every other team sees. They still inherit org-wide priorities and the decision register from the root.
The failure mode we hit early: every team writing context independently, without coordination. Within two months, three teams had contradictory escalation paths in their files, and two had different definitions of 'P1 incident.' The fix is a hard rule: the root CLAUDE.md owns all cross-team definitions. Sub-directory files reference root definitions — they do not redefine them. Otherwise drift compounds and the model gets confidently wrong answers about which severity scale applies.
Why the Decision Register Is the Highest-Leverage Section
Two specific failure modes the register prevents — both expensive, both invisible until they show up.
Teams make dozens of consequential decisions each quarter. Six months later, nobody remembers why you chose Postgres over DynamoDB, or why billing stayed a monolith. The decision register captures the reasoning at the moment it was made, blocking two specific failure modes.
First: it stops Claude from suggesting approaches the team already considered and rejected. Without the register, the model spends time building a case for the migration you ruled out three weeks ago. With it, the model knows the decision was made, understands the rationale, and works inside the constraint instead of relitigating it.
Second: it absorbs organizational amnesia when people leave. The EM who championed the Postgres choice rolls to a different team. The reasoning survives in the register — the institutional memory is no longer locked in a specific person's head.
Claude proposes DynamoDB for audit logs — you spend 10 minutes re-explaining why it was ruled out
New engineer suggests splitting billing into microservices — relitigates a settled debate
The security constraints behind the auth architecture are nowhere documented
Every session restarts the same context-rebuild cycle
Claude reads the register and works inside the existing constraints by default
New engineer sees the decision, rationale, and participants — onboard ramp shortens
Security constraints sit next to the decision they shaped
Every session starts with full historical context already loaded
Patterns That Work, Patterns That Rot the File
Organizational CLAUDE.md Rules
Keep the root file under 100 lines
Use @imports for detailed sections. A bloated root dilutes the signal that matters most.
Write facts, not instructions
CLAUDE.md encodes what is true about the org. Procedural how-to belongs in Skills.
Date every entry in the decision register
Undated decisions lose context fast. Date, participants, one-sentence rationale, every time.
Never store secrets or credentials
The file is version-controlled. Reference secrets by name only — keep the values in env vars.
Prune quarterly
Stale context is worse than missing context. Archive completed priorities and resolved experiments — drift is the default state without it.
Pointers over copies
Link to the canonical source. Duplicated content drifts out of sync with the original within weeks.
Getting Started: A 30-Minute Setup
CLAUDE.md Organizational OS Setup Checklist
Run /init in the project root to scaffold a starter CLAUDE.md
Team topology added: teams, leads, ownership areas — named
Top 3-5 quarterly priorities documented with rationale
decisions.md created and last 5 major decisions logged
Communication norms specified: async preferences, meeting cadence, RFC threshold
Active experiments listed with owner and end date
/update-context skill created in .claude/commands/
Weekly calendar reminder set to run /update-context
Sub-directory CLAUDE.md files created per team or service
Reviewed with the team — this is a living document, not a one-shot artifact
Operating Doctrine
How long should the org CLAUDE.md be?
Root file under 100 lines. Use @imports to pull in detailed files like teams.md or decisions.md. Imported files load on demand, keeping the base context lean while the detailed information stays accessible. Past 100 lines, the signal-to-noise ratio drops fast and the most important context gets buried.
Does this replace documentation?
No. CLAUDE.md is context for the model, not documentation for humans. It complements existing docs by pointing to them. Treat it as an index card that says 'here is what matters right now,' not a comprehensive manual. Mixing the two roles produces a file that fails at both.
How do we handle sensitive information — salaries, performance data?
Keep it out. The file is version-controlled and visible to anyone with repo access. Reference sensitive data sources by name — 'salary bands live in the HR system' — without including values. If Claude needs the actual data during a session, paste it inline where it stays session-scoped and never persists. The test: would you be comfortable seeing it in a public commit history? If no, it does not belong in any persistent context file.
What if teams disagree on what goes in the root?
The root holds only org-wide context that affects every team. Team-specific context belongs in nested CLAUDE.md files in each team's directory. The dispute resolves with one question: does this fact change how Claude should behave when working in any part of the codebase? If yes, root. If no, sub-directory. Re-routing this decision is what produces the contradictory escalation paths described above.
Can non-engineering teams use CLAUDE.md?
Yes. Marketing encodes brand voice guidelines, content calendars, and campaign priorities. Product documents personas, roadmap commitments, and A/B test outcomes. The pattern is layer-agnostic — any team that interacts with Claude has org context worth persisting.
The shift from CLAUDE.md as style guide to CLAUDE.md as organizational OS is not a technical lift. It is a reframing. You stop telling Claude about the code and start telling Claude about the organization.
Start small. Add team topology and the top three priorities this week. Build the /update-context skill next week. Inside a month, every session starts with the weight of your team's context, decisions, and direction already loaded — and the coordination tax you used to pay every conversation stops compounding.
- [1]Claude Code Docs — Best Practices(code.claude.com)↩
- [2]HumanLayer — Writing a Good CLAUDE.md(humanlayer.dev)↩
- [3]Anthropic Claude Blog — Using CLAUDE.md Files(claude.com)↩
- [4]Medium — Building a Personal CTO Operating System with Claude Code(obie.medium.com)↩
- [5]MorphLLM — Claude Code Skills, MCP, and Plugins(morphllm.com)↩
- [6]Anthropic Claude Blog — Skills Explained(claude.com)↩
- [7]Damian Galarza — MCPs vs Agent Skills(damiangalarza.com)↩
- [8]DeepWiki — CLAUDE.md Files and Memory Hierarchy(deepwiki.com)↩