Course · Copilot · Prompt files & slash commands
Prompt vs rule - invoked vs always-on
A rules file and a prompt file look similar: both Markdown in .github/, both feed Copilot context, both kill repetition. But they fire at completely different times, and that difference is the whole placement decision.
The one difference that matters
Section titled “The one difference that matters”Rules are always-on. A copilot-instructions.md file is applied automatically, on every request, whether or not you are thinking about it (path-specific *.instructions.md files, whenever the files being edited match their glob). You do not invoke it. It is ambient - Copilot pulls it into the conversation on its own, every time.
Prompt files are invoked. A .prompt.md does nothing until you call it with a slash command - a named shortcut typed in the chat input. It sits in the repo, inert, until the moment you decide now I want this procedure run. It applies exactly once, exactly when you ask.
Everything else follows from that. The question for any piece of repeated work: should this apply to every request, or only when I ask for it?
When you want always-on
Section titled “When you want always-on”If the thing should shape every answer Copilot gives in this repo, it is a rule. House style is the clean example: “match the existing sort idiom,” “emit audit events the way the other endpoints do,” “lay out files this way.” You want those true of every draft - bug fix, scaffold, or question - so they belong in the ambient layer.
The test: if you forgot to mention this and Copilot did the opposite, would that be a mistake? Forgetting the sort idiom is a mistake. So the idiom is always-on.
When you want on-demand
Section titled “When you want on-demand”If the thing is a specific task you only want sometimes, it is an invoked procedure. “Scaffold an audited endpoint” is the counter-example: most requests are fixes and questions, and a scaffold firing unasked would be noise or worse. You want it precisely when you sit down to add an endpoint, not one moment otherwise.
The test inverts: if this fired on a request where you did not ask for it, would that be wrong? An endpoint scaffold firing while you fix a sort bug would be wrong. So it is on-demand - a prompt file where the Local harness is in use, and a skill carrying the same steps for other harnesses (as of October 2026). How often you run it changes what the container costs, not which test decides - the widget’s frequency economics and this consent test answer different questions.
They’re partners, not rivals
Section titled “They’re partners, not rivals”The strongest setup uses both at once. The prompt carries the procedure - the ordered steps. The rules carry the conventions - how the resulting code should look. When you invoke the prompt, the rules are still applied underneath it, because they are always-on; the scaffolded endpoint comes out in house style without the prompt restating a single style instruction. That is why the prompt’s body can end with “follow the repository’s custom instructions” and mean something.
Think of it as: rules are who Copilot always is in this repo; invoked procedures are tasks you hand it on demand. The same economics govern both - and the third container, the model-invoked skill, is in between: loaded only when needed, but chosen by the agent rather than by you. In the widget below, “rules file” is the always-on layer, “prompt” is just saying it in chat, and “skill” is the invoked container as the format prices it: an always-present stub plus the body when it fires. Read the rows with care: the “prompt” row is only knowledge you retype by hand - an invoked prompt file prices like the skill row minus the stub, inert on disk until you run it. The two models converge when a prompt file is converted to a skill:
You have the placement judgment. The last step is making a prompt file itself more capable - accept a parameter, pin the role it runs in, control its tools. Next: Arguments, agent, and tools.