Create a prompt file

You’ve decided the “scaffold an audited endpoint” request is worth saving instead of re-typing. Let’s turn it into a prompt file.

Where prompt files live

A prompt file is a Markdown file with a .prompt.md extension. By default Copilot looks for them in a .github/prompts/ folder at the root of your workspace — so this prompt ships in the repo, version-controlled, and everyone on your squad gets it the moment they pull. That’s the whole point: the team task lives where the team can see it, not in one person’s chat history.

If you want Copilot to look somewhere besides .github/prompts/ — a shared folder, a personal one — the chat.promptFilesLocations setting controls which directories it scans. For the team-shared case the default location is exactly what you want; leave it.

Let Copilot draft it for you

You can write a .prompt.md by hand, but you don’t have to start from a blank file. Copilot has a generator for this: run /create-prompt in the chat, describe the reusable task in plain language, and it scaffolds the file — frontmatter and body — for you to refine. It’s the same move you’d make for any boilerplate: let the agent do the first draft, then you read and tighten it.

Describe the task the way you’d describe it to a teammate:

A prompt that scaffolds a new audited endpoint the way our team does it: add the route, run inputs through the validation helper, enforce the configurable approval threshold, record an audit event via shared-lib, and stub a test.

Copilot writes the file. Now read it — because a prompt file you’ll run dozens of times deserves the same scrutiny as code.

What the prompt file holds

Open the generated file under .github/prompts/. The body is the prompt itself — the instruction Copilot will follow when you invoke it. Make it concrete and ordered, the way you’d actually want the work done:

---
description: Scaffold a new audited endpoint following our team's conventions.
---

Scaffold a new audited endpoint for orders-service. Steps:

1. Add the route handler in the conventional location for this service.
2. Run incoming inputs through the shared-lib validation helper.
3. Enforce the configurable approval threshold: orders at or above it
   require a second approver before the action proceeds.
4. Record an audit event via the shared-lib audit helper, matching how
   the existing endpoints emit their events.
5. Stub a test covering the below-threshold and at-or-above-threshold paths.

Follow the repository's custom instructions for style and structure.

Two things to notice. First, that last line leans on the rules you wrote last chapter — the prompt file says what procedure to run, and the always-on instructions handle how the code should look. They compose: the prompt brings the steps, the rules bring the house style. Second, “an audited endpoint” is your team’s shorthand for exactly this shape — an endpoint that records an audit event through shared-lib — and now that shorthand is executable.

The frontmatter so far is just a description. That’s enough to run it. The next lesson adds the rest — a name, parameters, the mode it runs in — but a prompt file does its job with nothing but a body and a one-line description.

Invoke it

Three ways to run a prompt file, all equivalent:

• Type / and its name in the Chat view. Copilot lists your prompt files as slash commands; pick the one you just made and it runs. This is the everyday path — it’s why people call them “slash commands.”
• Run the “Chat: Run Prompt” command from the Command Palette and choose the file.
• Open the .prompt.md file and click the play button in the editor — handy while you’re still tuning it.

Run it once on orders-service. Copilot executes your five steps in order and comes back with the scaffolded endpoint as a reviewable change — the same proposes-you-decide loop from your first chapter, except you triggered five steps with one slash command instead of typing them out.

You now have a working prompt file. But you also have a fair question: you just wrote conventions into a rules file last chapter, and now you’re writing a task into a prompt file — when does a thing belong in which? Next: Prompt vs rule — invoked vs always-on.