What earns a place in the file

Copilot gives you several standing-context mechanisms: a repo-wide instructions file, reusable AGENTS.md / CLAUDE.md convention files, path-specific rules for directories that need them, and a precedence order when layers disagree. The mechanics are the easy part. The skill that decides whether a rules file helps or quietly hurts is judgment about what goes in it. 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 does not, and it spends context budget restating things Copilot already knew. 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 come straight from your correction history. You watched Copilot reach for the wrong sort idiom and corrected it by hand more than once - so the convention earned a line. You watched it log directly instead of going through the audit helper and nudged it back every time - so that convention earned a line. 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 - a longer file without a single better draft.

That overhead is measurable, not a vibe. The ledger below holds seven illustrative candidate lines - toggle each into the file and watch what it costs and saves. Read the two amber categories differently: the lines marked the model already knows never save anything, so cutting them improves the ledger immediately; the one week of value lines can look net-positive this week, which is exactly their trap - their value expires while their rent continues. Cut the first kind on sight; cut the second when its week is over, and say the fact in the prompt where it belongs:

Seven candidate lines for your rules file. Toggle each one in and see whether it earns its slot over a week of sessions.

• Tests run with npm test -- --runInBand - parallel runs deadlock the test DB.earns its slotWithout it, the agent runs plain npm test, hits the deadlock, and you explain - most sessions. One line ends that forever.
• Use pnpm, never npm - the lockfile is pnpm’s and npm install corrupts it.30 tok
• Route handlers never throw - return Result<T, AppError> from src/lib/result.ts.36 tok
• The bug we’re fixing today is in src/billing/charge.ts.18 tok
• Current sprint: migrate the users table to UUID keys.16 tok
• Write clean, readable code with good variable names.the model already knowsThe model does this by default. The line buys nothing - it just competes with your real rules for attention.
• Think step by step and be careful about edge cases.14 tok

always-loaded cost480 tok/weekre-teaching avoided5.6k tok/weeknet+5.1k tok/week

Net positive - but 1 line is paying rent with the durable facts’ savings. Cut the amber ones; the ledger only improves.

Numbers are illustrative - the ratios are the point: a re-teach cycle (wrong attempt, correction, redo) dwarfs the line that prevents it. Assumes 10 sessions a week, the file loaded at the start of each.

What doesn’t earn a place

• The obvious. “Write clean, readable TypeScript.” “Add error handling.” “Use meaningful names.” Copilot does these unasked; the line only adds noise. Good rules are specific, local, surprising - the repo’s sort helper, the audit-event union, the order an endpoint does its work in. Things a new teammate learns only by getting a review comment.
• What the code already enforces. If a linter, formatter, or type checker catches it, the tool is a more reliable enforcer than a sentence in a file. Do not write “use 2-space indentation” when Prettier exists. Spend the file on what cannot be mechanically enforced: which helper to reach for, which patterns your team decided against, how the pieces fit.
• Anything that’s really documentation. A rules file is not the 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.
• Time-bound facts. “The bug we’re fixing today is in charge.ts” is true today, noise tomorrow, misleading next month. Facts with an expiry date belong in the prompt, not in a file every future session loads.

Keep them tight

Treat the file the way you treat a function: every line pulls its weight, and length is a cost. A short file of sharp, specific rules beats a long file of vague ones every time - Copilot follows a focused instruction more reliably, and a file readable in thirty seconds is a file your team will actually keep current. When a rule stops earning its place - the convention changed, the helper was 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.

Try it

Open your repo’s rules file (.github/copilot-instructions.md, unless you chose a different home) and delete one line you suspect Copilot does not need. Run your next few tasks and watch for the correction that line used to prevent. If it never comes back, the line was overhead; if it does, restore it - now you know what it was buying.

The discipline underneath

Step back from Copilot for a moment, because what you just practiced outlives the tool. You took knowledge that lived in your head and got re-typed on every request, moved it into files the agent reads automatically, and then got disciplined about keeping only the parts that change the output. That is 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 judgment is the same whether the agent is Copilot, Claude Code, or whatever you pick up next year.

Conventions are handled now, and first drafts conform without a word from you. But there is a different kind of repetition the rules file cannot fix - not “how should this code look” but “do this exact multi-step task again.” When you catch yourself re-typing the same procedure into chat, that is a job for a different primitive. Next chapter: prompt files & slash commands.