Prompt vs rule — invoked vs always-on

You now own both tools. Last chapter you wrote a rules file; this chapter you wrote a prompt file. They look similar — both are Markdown in .github/, both feed Copilot context, both kill repetition. But they fire at completely different times, and that difference is the whole decision.

The one difference that matters

Rules are always-on. A copilot-instructions.md or an *.instructions.md file is applied automatically, on every request, whether or not you’re thinking about it. You don’t invoke it. It’s ambient — Copilot pulls it into the conversation on its own, every time, and you’d have to go out of your way to not get it.

Prompt files are invoked. A .prompt.md does nothing until you call it with a slash command. 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 is simply: should this apply to every request, or only when I ask for it?

When you want always-on

If the thing should shape every answer Copilot gives in this repo, it’s a rule.

Your 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 don’t want those sometimes — you want them whether you’re fixing a bug, scaffolding an endpoint, or answering a question in Ask mode. Anything you’d want true of every draft, regardless of what you happened to ask for, belongs in the always-on layer. That’s why you wrote them as rules last chapter: re-typing “match the style” on every request was the signal that it should’ve been ambient all along.

The test: if you forgot to mention this and Copilot did the opposite, would that be a mistake? If yes, it’s a rule. Forgetting your sort idiom is a mistake. So it’s always-on.

When you want on-demand

If the thing is a specific task you only want sometimes, it’s a prompt file.

“Scaffold an audited endpoint” is the clean counter-example. You absolutely do not want that running on every request — most of the time you’re fixing a bug or asking a question, and a prompt that scaffolds a whole endpoint would be noise, or worse, an unwanted action. You want it precisely when you sit down to add an endpoint and not one moment otherwise. That’s an invoked procedure, not an ambient convention.

The test inverts: if this fired on a request where you didn’t ask for it, would that be wrong? If yes, it’s a prompt file. An endpoint scaffold firing while you’re fixing a sort bug would be wrong. So it’s on-demand.

They’re partners, not rivals

The strongest setup uses both at once, and your endpoint scaffold already does. The prompt file carries the procedure — the five 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’re always-on. So the scaffolded endpoint comes out in your house style without the prompt file having to restate a single style instruction. That’s why the prompt’s body could end with “follow the repository’s custom instructions” and trust it to mean something: the always-on layer is already there.

Think of it as: rules are who Copilot always is in this repo; prompt files are tasks you hand that person on demand. You don’t choose between them — you decide, for each bit of repeated work, which layer it lives in.

You’ve got the judgment. The last thing is to make the prompt file itself more capable — accept a parameter, pin a mode, control its tools. Next: Arguments, agent, and tools.