Prompt Files, Explained From Zero

Custom instructions solved the “rules that apply to everything” problem. Prompt files solve a different one: the specific, repeatable task prompt you keep needing — and they turn your one-off prompting effort into a permanent, shareable tool.

1 · The prompt you keep retyping

Maybe you've crafted a really good prompt for “review this code for security issues,” or “write tests following our patterns,” or “generate a component from this spec.” The first time took effort. But every time after, you retype it from memory — slightly differently each time, forgetting the good bits — and everyone on your team reinvents their own version. That's wasteful, because a good prompt is a genuine asset, like a good script. Prompt files let you save that perfected prompt as a reusable file you run with a click — turning a one-off effort into a permanent tool.

2 · A saved, runnable prompt

A prompt file is exactly what it sounds like: a file containing a prompt. In Copilot it's a Markdown file ending in .prompt.md, kept in your project. Inside, you write the full, polished prompt for a task — all the instructions, context, and format you learned makes it work. Then, instead of typing that prompt, you invoke the file by name in chat, and the assistant runs it. You've turned a block of text you used to retype into a named command. It's like a saved recipe versus cooking from memory: once written and tested, anyone can produce the same good result by following it. The effort happens once; the benefit repeats forever.

3 · It can take inputs

Prompt files get more powerful because they can take inputs, making them reusable across many situations. Instead of hard-coding a specific file, a prompt file can include a placeholder — “write tests for this file” where the file is filled in when you run it. So your “write tests” prompt file works on any file: you invoke it, point it at whatever you're working on, and it applies the same careful, tested instructions to that target. This is the leap from a fixed note to a genuine template — a form with blanks you fill in each time. It's the same idea as a function in programming: write the logic once, with parameters, and call it with different arguments whenever you need it.

4 · A worked example

Say your team builds a lot of API endpoints, and there's a right way to do it. You write a prompt file, new-endpoint.prompt.md, that says: create a REST endpoint with this name, follow the patterns in our /lib/api folder, add input validation, proper error handling, and a Vitest test. Now, whenever anyone needs a new endpoint, they run that file and type the name — and out comes an endpoint matching your standards every time, complete with validation, error handling, and a test. No one has to remember all those requirements; they're captured in the file. You've encoded your team's best practice for a common task into a button.

5 · Prompt files vs. custom instructions

These two pair up beautifully, so keep them straight. Custom instructions are always on — the standing background rules added to every request, describing your project in general. Prompt files are on demand — a specific task you deliberately invoke. Instructions say “here's how we do things, always”; prompt files say “do this particular job, the way we've perfected it, now.” They complement each other: your instructions set the baseline conventions, and your prompt files are specialised tools built on that baseline. A “write tests” prompt file needn't restate your testing philosophy, because your custom instructions already carry it.

6 · Share them, version them

Like custom instructions, prompt files live in your repository, which turns them from personal tricks into team infrastructure. When your best prompts are committed files, everyone can use them, improve them, and rely on them. Your strongest prompt-writer's expertise gets captured and shared instead of trapped in their head. New teammates inherit a ready-made toolkit the moment they clone the repo. And because they're versioned like code, you can review changes, track what improved, and roll back a prompt that started producing worse results. This is how mature teams work with AI — a shared, version-controlled library of tested prompts. Your prompting knowledge stops evaporating and starts compounding.

7 · Start with your most-repeated task

Don't build a whole library at once — start with your single most-repeated task, where a prompt file pays back fastest. What do you request over and over? Writing tests, reviewing code, scaffolding a component, drafting a commit message? Take the one you do most, spend a little time getting the prompt genuinely good, and save it as your first prompt file. Use it for a week, refine it when it stumbles, then add the next one. Built this way, your library grows naturally around your actual work rather than as a big upfront chore. The best first prompt file is simply the prompt you're tired of retyping.

8 · A simple test you can run this week

9 · Glossary — every term, spelled out

Prompt file

A file (.prompt.md) holding a polished, reusable prompt you invoke by name.

Placeholder / input

A blank in a prompt file (like ${file}) filled in when you run it, so one file works on many targets.

Named command

A saved prompt you invoke instead of retyping — like a function you call.

On demand

Run only when you invoke it — the opposite of always-on custom instructions.

Team infrastructure

Committed, shared, versioned prompt files that any teammate can use and improve.

Prompt library

A growing collection of your team's tested prompt files, built one high-value task at a time.