What earns a place in the file

You now know every mechanism: the repo-wide file, the AGENTS.md / CLAUDE.md bridge, path-specific rules, the precedence order. The mechanics are the easy part. The skill — the thing that decides whether your rules files help or quietly hurt — is judgment about what goes in them. A rules file is read on every request, and a bloated one costs you twice: it dilutes the rules that matter under a pile that doesn’t, and it spends context budget restating things Copilot already knew. So the question for every candidate rule is the same: does writing this down change what Copilot produces?

The test: write down what it keeps getting wrong

The best rules in your files came straight from your correction history. You watched Copilot reach for the wrong sort idiom in orders-service, and you’d corrected it by hand more than once — so it earned a line. You watched it log directly instead of going through the audit helper, and you’d nudged it back every time — so the audit-event convention earned a line. That’s the whole heuristic:

If Copilot keeps getting something wrong and you keep correcting it, write the correction down. If Copilot already gets it right, leave it out.

A rule that captures a real, repeated miss pays for its place on every future request. A rule that restates what the model already does correctly is pure overhead — it makes the file longer without making a single draft better.

What doesn’t earn a place

• The obvious. “Write clean, readable TypeScript.” “Add error handling.” “Use meaningful names.” Copilot does these without being told; the line only adds noise. The good rules are the specific, local, surprising ones — your repo’s sort helper, your audit-event union, the order an endpoint does its work in. Things a new teammate would only learn by getting a review comment.
• What the code already enforces. If a linter, formatter, or type checker catches it, you don’t need a rule for it — the tool is a more reliable enforcer than a sentence in a file. Don’t write “use 2-space indentation” when Prettier already does. Spend the file on what can’t be mechanically enforced: which helper to reach for, which patterns your team has decided against, how the pieces fit.
• Anything that’s really documentation. A rules file is not a place to explain the whole architecture. If a paragraph is teaching the system rather than steering the next draft, it belongs in a doc the rule can point at, not in the always-on file.

Keep them tight

Treat the file the way you’d treat a function: every line should pull its weight, and length is a cost, not a virtue. A short file of sharp, specific rules beats a long file of vague ones every time — both because Copilot follows a focused instruction more reliably, and because a file you can read in thirty seconds is a file your team will actually keep current. When a rule stops earning its place — the convention changed, the helper got removed, the miss stopped happening — delete it. Rules files rot exactly like stale comments, and a wrong rule is worse than a missing one, because Copilot will faithfully apply it.

The discipline underneath

Step back from Copilot for a second, because what you practiced in this chapter outlives the tool. You took knowledge that lived in your head and got re-typed on every request, and you moved it into files that the agent reads automatically — and then you got disciplined about keeping only the parts that change the output. That’s context engineering in miniature: identify the gap between what the agent guesses and what your team knows, close it once in a durable place, and prune it so it stays true. The file is just where it lives. The judgment about what goes in it is the actual skill, and it’s the same judgment whether the agent is Copilot, Claude Code, or whatever you pick up next year.

Your conventions are written down now, and Copilot’s first drafts conform without you saying a word. But there’s a different kind of repetition the rules file can’t fix — not “how should this code look” but “do this exact multi-step task again.” When you find yourself re-typing the same procedure into chat — scaffold an audited endpoint our way, with validation, the audit call, the tests — that’s a job for a different primitive. Next chapter: prompt files & slash commands.