CLAUDE.md at team scale, in brief
Lesson 1 established the track’s spine: architecture is deciding where judgment lives. Lesson 2 is the track’s first code-reading lesson, and the code is configuration: markdown files, a little YAML, a folder layout. The judgment is in where the files go, because in Claude Code, where a configuration file lives decides who receives it.
The capability: after this lesson, you can look at a team’s Claude Code setup and say where each instruction should live, which rules deserve enforcement rather than prose, why two teammates get different behavior from the same model on the same repository, and how to fix it.
What the lesson covers. The memory hierarchy runs from personal (a file in your home directory) through project (committed, shared with the whole team) and local (gitignored) to subdirectory files that load on demand, plus a managed tier for organizations. Loaded files concatenate rather than override, so one audience question does most of the work: who needs to receive this decision? Memory shapes judgment but does not enforce it; rules that must always hold move to settings and hooks. Rules files scoped by path patterns load only with the code they govern, which is the carry versus fetch trade-off applied to configuration. Slash commands turn a team workflow into a committed, reviewable file. Plan mode is treated as a per-change risk decision: direct execution for small, well-scoped work, a reviewed plan for large, ambiguous, or sensitive changes.
The closing section names the failure mode the lesson opens with: configuration drift, “works on my machine” for judgment, diagnosed by inventorying loaded files and fixed by promoting team decisions into the repository.
Why this order. The track’s working frame here is configuration as a product: it has users, releases, and bugs. A decision committed to the repository outlives the person who made it. That is what makes an architect’s judgment durable.