Skip to content

Course · Copilot · Rules (custom instructions)

Rules (custom instructions)

If you have worked with Copilot chat (or any coding agent) for more than a day, you have typed the same instructions twice. “Match the existing style.” “Use the audit helper (the shared-library routine that records significant events) the way the other events do.” “Sort the way this file already sorts.” It works - you say it, Copilot does it - but you are re-stating knowledge that never changes between requests, and the moment you forget, Copilot guesses, and guesses differently than your team would.

That repetition is the signal this chapter answers. The conventions are not changing between requests; you are re-typing them between requests. Written down once, in a file Copilot reads automatically, they stop being something you remember to say and become something the tool already knows.

A rules file is persistent context. Instead of living in your head and getting re-typed into chat, your conventions live in a file in the repo, and Copilot pulls that file into the conversation on its own - every request, no reminder. The payoff is not that Copilot gets smarter. It is that its first draft lands closer to mergeable, because the things it used to guess are now stated: less back-and-forth, fewer “actually, we do it this way” corrections, more diffs that pass review on the first read.

This is context engineering in its most concrete form. What the agent knows decides what its first attempt looks like; a rules file is the cheapest lever on that knowledge you own. The chapter’s example writes rules for two inherited repositories - an order service and a shared library that other services import - and finds that the library, where a sloppy change ripples outward, needs stricter and more specific rules than the app.

From the simplest rules file to the judgment of what belongs in one:

Start with the file every surface in this course supports - repo-wide instructions with copilot-instructions.md.