A committed .github/copilot-instructions.md prepends a repository's invariants to every Copilot request

The file goes in front of the request. The post says .github/copilot-instructions.md is prepended to every request, so each of its lines occupies the same context as the question you actually asked ^[1][8]. Length is therefore a cost. A 400-line instruction file is a tax on every interaction and dilutes the rules that matter among the ones that do not, according to the post ^[8]. Its floor is five lines, kept for the non-obvious ones ^[9]. Five to 400 spans a factor of 80, paid per request ^[10].

Phrasing plateaus for a reason the author states directly. "Better phrasing asks the model to try harder. It does not tell the model anything it did not already know," he wrote ^[2].

So the test for a rule is informational. "Write clean, maintainable code" costs context and changes nothing, because the model already agrees with it ^[3]. A rule saying money is Decimal and never float, rounded half-up to two places at the response boundary only and never mid-calculation, states a fact about one codebase that cannot be read off the code the model can see ^[4]. The post asks for three properties in every rule: durable, specific, and checkable, where checkable means a reviewer can look at a diff and say whether the rule was followed ^[6].

Wording shows up in the file itself. A rule that names datetime.utcnow() and says it returns a naive datetime while this codebase compares against aware ones gets followed, per the post, while "Use timezone-aware datetimes" gets agreed with and then not done ^[5]. The reason clause is what keeps the rule alive in a situation the author did not anticipate ^[7].

Two conditions have to hold before any of this moves output in your repository. The invariant has to be one the model cannot infer from the code it can see ^[4]. The surface you use has to read the file, and on that the post defers to GitHub's documentation, which it says covers path-specific instruction files, the precedence order when several apply, and which surfaces read which file ^[19]. The post does not report a before-and-after measurement of generated code; its evidence is the author's own practice ^[20].

Infrastructure is where the author says the pattern pays best, because the mistakes are more expensive ^[23]. In the Terraform set, count is positional, so removing the second of three items destroys the third ^[12]. The Kubernetes rules ask for three probes pointing at different endpoints, because a liveness probe that duplicates readiness turns a slow dependency into a restart loop ^[13]. For GitHub Actions, nothing under github.event may be interpolated into a run: block, and it goes through env: instead ^[14]. Nine rules across the three stacks ^[16], and each names a defect class the post calls invisible in review because the wrong version looks exactly like the right version ^[15].

The property the author rates highest is administrative. The file is committed and reviewed like code, so a convention stops being one person's preference and becomes something the team approved, with a history, changed by pull request ^[17]. He wrote that he has watched a fifteen-minute argument about a convention end with someone saying to put it in the instructions file, crediting the file with turning a preference into a proposal somebody had to approve ^[18].

The closing instruction is narrow: three rules about the repository that a competent new joiner would get wrong in the first week, no style, nothing the linter catches ^[21]. That, the author wrote, "will take ten minutes and outperform every prompt-engineering tip you have read, including this one" ^[22].