Distilling Rules
Rules you have to repeat go into CLAUDE.md and Skills.
Rules you keep repeating go into project files, so you don't have to say them again. But that file has to stay lean—otherwise it becomes noise itself.
What you'll run into:
- Every new session starts with restating the project's rules from scratch
- The rules file grows longer and longer, until it stops being followed
- It still holds rules from three months ago that nobody does anymore
What to distill
| Type | Example |
|---|---|
| Technical rules that cause rework | Permissions always checked on the backend, money computed server-side, secrets never in code |
| Site-wide design conventions | Spacing only from these six values, colors only from tokens, components must implement four states |
| Explicit non-goals | No team collaboration, no mobile app. Stops "just add it while you're at it" |
| Collaboration style | Propose before coding, update the spec before changes, self-check and report when done |
| Project entry info | Directory conventions, how to run commands, where components live |
The flip side: what should NOT go in is rules that only hold inside one module (that's a spec), descriptive project introductions (they don't constrain any behavior), and one-off temporary requirements.
How to write it
- Write imperatives, not descriptions. "Spacing only in multiples of 4" is a constraint; "this project uses a 4px grid system" is an intro. The latter doesn't change its behavior.
- Section by headings, items by short lines. Clear sections let it jump to the relevant part instead of re-reading the whole thing each time.
- Add a why only on the critical ones. Knowing the reason lets it apply the rule correctly in edge cases. But only on the few that matter—not on every line.
- Put it at the very front. The start and end of context are best remembered; the middle gets ignored.
How to keep it from bloating
A rules file is not a hard switch; the model follows it probabilistically. The longer it gets, the lower the chance each line is taken seriously—which is why it has to stay thin. Context engineering points the same way: context is a scarce resource, and the thinner the file, the higher the chance the key rules are actually attended to. Before adding anything, ask whether it's worth the budget.context-eng
To maintain it, use the line-by-line sieve: if deleting this line wouldn't cause a mistake, delete it. Half of most people's rules files is describing the project rather than constraining behavior. A few hard numbers: under 200 lines, every line maps to a concrete behavior, prune the outdated once a month, and before adding a new rule see whether an existing one can absorb it.
One more practice: after the rules are written, restate the few key ones in the current instruction anyway. The file holds the long-term baseline; the instruction holds the focus for this run. The two are not substitutes.
One level up: skills
Rules govern "what to follow when doing the work." One level above that is "how to do a certain kind of task"—for example, a fixed release process, or the way a walkthrough checklist is run. This kind of content is longer and more process-like; it fits better as a standalone file you call in when needed, rather than something that sits in context every time.
The test is simple: what has to take effect every time goes into the rules; what you only reach for occasionally becomes a callable file. That keeps the rules file thin while the complex processes don't get lost. The reverse also holds: if a rule only matters in a certain kind of task, move it out of the rules file into that skill, so it stops occupying context on every run.