context-baselinelisted

# Context baseline Most mid-implementation questions are a missing line in `CLAUDE.md`. This skill converts what the team knows into what the agent reads on every run. The hierarchy matters wherever a repo holds more than one deliverable: there are repo-wide truths and per-project truths, and mixing them produces a root file so long that neither gets read. Root holds what is true everywhere. Each project's file holds what is true only there. A single-package repo needs one file — the hierarchy is a response to divergence, not a requirement. ## What belongs in these files The test for every line: **would the agent get this wrong by default, and can it not find the answer by looking?** Write down what the environment does not confess: - **Unwritten conventions** — "container components own data fetching, presentational ones take inputs only". No config states this; every reviewer expects it. - **Reasons behind choices** — "we use the facade pattern over direct store access because the store shape is migrating". Prevents an agent from "simplifying" a deliberate indirection. - **Gotchas** — "the dev server needs the mock backend on :4010 first, otherwise the login guard loops". Costs an hour to rediscover, one line to record. - **Local deviations** — "this app still uses the old form library; do not port it opportunistically". - **Hard boundaries** — what must never be touched without a human: generated files, vendored code, anything under a `legacy/` path. Leave out what