Build a Reusable GitHub Copilot Prompt Library

A prompt library is not simply a collection of prompts. It is a small set of agreed tasks that a team performs the same way, stored where the code is and reviewed like the code.

The distinction matters because the collection version fails in a predictable way: someone enthusiastic writes forty files, nobody can find the right one, and within a month everyone is back to typing prompts by hand.

What goes in a library

The test for whether something belongs is repetition you can point at. Not “this would be useful” — “I have typed this three times”.

In practice most teams converge on six to ten files covering:

Six files, six distinct jobs, no overlap. Someone opening the prompt selector can read the list and know which one they want without opening any of them — which is the only test of a library that matters day to day.

Naming

The filename and the description are your entire discoverability mechanism, because prompt files are invoked manually and a file nobody finds does nothing.

Name for the task, not the topic. generate-tests beats testing. review-security beats security. A verb tells the reader what will happen.

Use the same verbs consistently. If you have review-security and review-correctness, do not also have check-performance — make it review-performance. Consistent prefixes make a list scannable and make gaps obvious.

Keep names short enough to read in a dropdown. review-changes-for-security-issues-before-merge is accurate and unusable.

Structure inside each file

The files that stay useful share a shape.

A stated goal. One sentence at the top saying what this file does and when.

Constraints. What the model must not do. This is where a team’s conventions live — “do not modify production code”, “do not add dependencies”, “follow the existing test structure”.

An output specification. What should come back, in what form. For review prompts: what a finding contains. For generation prompts: which files may change.

A handling rule for the empty case. “If you find nothing, say so plainly.” Without it, review prompts manufacture marginal findings, because reporting nothing feels like failing the task.

A self-check, where it applies. Asking the model to evaluate its own output — “which of these tests would fail if the logic were inverted?” — catches a useful fraction of the characteristic defects.

Why version control is the point

Everything above could live in a shared document. Four things change when it lives in the repository.

Review. A prompt that shapes how code gets written deserves the scrutiny of a pull request. A review prompt missing a whole category of problem is worth catching before it silently becomes the team’s definition of “reviewed”.

History. When a prompt improves, the improvement has a commit message and a reason. Six months later you can see why the security prompt gained a clause about deserialisation — usually because something got through.

Consistency. Two developers invoking the same file get comparably-shaped output. Two developers with their own remembered version get output that differs in ways nobody can account for.

Discoverability for newcomers. A new colleague can read .github/prompts/ and learn how the team works. They cannot read your notes.

That last step is not a failure. It is the mechanism that keeps the library small enough to be usable, and a library with no deletions in its history is almost always one that has stopped being used.

The size problem

The instinct is to add. Adding a prompt file is cheap and feels productive; evaluating whether one earns its place is neither.

The result is a library that grows monotonically until choosing between files is its own task — at which point people stop choosing and start typing prompts by hand, which is where they began.

Two rules keep it in check.

If you cannot say in one sentence how two files differ, they should be one file. Overlapping purposes are the main driver of libraries that are hard to use.

Delete anything nobody has invoked in three months. If it turns out to have been useful, git remembers it. The cost of deleting a good file is low; the cost of keeping ten bad ones is a library nobody opens.

What does not belong

Rules that must always apply. These go in repository instructions, which apply automatically and work on all nine Copilot surfaces. A prompt file containing “always run the tests” only runs the tests when someone remembers to invoke it.

Anything secret. These files are committed and readable by everyone with repository access. Policy belongs in them; credentials, internal hostnames and customer identifiers do not, and a prompt file is an easy place to forget that because it reads like a note to yourself rather than like configuration.

Environment specifics that will move. A prompt naming .venv/bin/python -m pytest breaks silently when you migrate tooling. Prefer “run the project’s test suite” where you can, and accept the maintenance where you cannot.

One-off tasks. A prompt for this sprint’s migration is a prompt, not a file.

A worked library, file by file

Six files, with the reasoning behind each. The point is not to copy them — it is to see what “one job, clearly scoped” looks like six times over.

explain-module.prompt.md — read-only orientation. Used when someone touches an unfamiliar part of the codebase. It asks for entry points, data flow and anything that looks unfinished, and explicitly forbids changes. This is the file new joiners use most, and the one most likely to be invoked several times a week.

generate-tests.prompt.md — the highest-volume file in most libraries. It names the case categories rather than saying “add tests”, specifies assertion style, and ends with a self-check asking which tests would survive an inverted implementation.

review-correctness.prompt.md — off-by-ones, inverted conditions, unhandled error paths, behaviour changes outside test coverage. Explicitly excludes style and naming, because a review that mentions both produces a list too long to act on.

review-security.prompt.md — input-to-sink tracing, credential scanning, authorisation checks, unsafe defaults. Separate from correctness deliberately: two focused passes find more than one general one, and the security pass is worth running on a narrower set of changes.

document-function.prompt.md — the house docstring format, plus the instruction to document what the code does rather than what the name implies. That clause turns documentation into a review and regularly surfaces real bugs.

pr-description.prompt.md — problem, approach, what to look at carefully, how it was tested. Plus the question about which part was hardest to reason about, which predicts where reviewers will skim.

Measuring whether the library works

Libraries are easy to create and easy to leave unexamined. Three signals tell you whether yours is doing anything.

Invocation, if you can see it. Where tooling shows which prompts get used, the distribution is usually stark: two files carry most of the usage and several have never been invoked by anyone but their author. That is not a problem to fix by promotion; it is information about what to delete.

Whether people ask for new ones. A library that is working generates requests — “can we have one for X?”. A library nobody uses generates silence.

Whether output has become more consistent. The point of a shared review prompt is that two people reviewing similar changes surface similar things. If review comments still vary wildly by who ran them, the file is either not being used or not specific enough.

None of these is rigorous, and none needs to be. They exist to catch the library that has been sitting in .github/prompts/ for a year with nobody able to say whether it helps.

Governance

Once a library exists and people use it, it is shared infrastructure and behaves like it.

Someone should own it. Not to write everything, but to notice when it has grown to fifteen files with overlapping purposes and do something about it. Shared resources with no owner drift toward whatever shape the most recent contributor preferred, and prompt libraries drift faster than most because each addition looks individually reasonable.

Changes go through review. Particularly changes to review prompts, which are in practice the team’s definition of what gets checked.

Revisit periodically. A prompt encoding a convention the team abandoned is actively harmful, because it argues confidently for something nobody believes any more — and it does so to whoever is least equipped to know better, which is usually the newest person on the team.

Watch for workarounds. If a colleague habitually types their own version of a prompt you have a file for, the file is wrong. That is free feedback and it is worth acting on rather than explaining why the file is correct.

Serving colleagues the library cannot reach

Three IDEs. Anyone on the CLI, Eclipse, Xcode or GitHub.com gets nothing from a prompt library, and pretending otherwise leaves part of a team quietly worse served.

Three things help.

Put the substance in instructions. Everything the library encodes about how your team works — conventions, constraints, validation expectations — should be in .github/copilot-instructions.md too, where every surface reads it. The prompt files then carry only the task-specific framing, which is the part that genuinely needs invoking.

Keep the prompts readable as prose. A colleague who cannot invoke review-security.prompt.md can still open it, read it, and paste the relevant part. That works if the file is written as a clear request; it does not if it is full of frontmatter-dependent behaviour.

Do not build workflows that assume everyone has them. “Run the review prompt before requesting review” is a process step that a third of your team cannot follow. If a check matters that much, it belongs in CI.

Rolling one out

The most common failure is a library one person wrote that nobody else uses.

Start from what people already type. Ask colleagues what they find themselves asking Copilot repeatedly. Those answers are your first three files, and they arrive pre-validated.

Introduce them in context. A prompt file for pull request descriptions is discovered when someone is writing a pull request description — mentioning it in a review comment once beats announcing it in a channel.

Accept partial adoption. Three IDEs, and within those, people with their own preferences. The library does not need everyone to be worth having.

Do not mandate it. A prompt library imposed as policy gets used badly or worked around. One that is genuinely more convenient than typing gets used because it is more convenient, and that is the only durable form of adoption available for a tool people can trivially ignore.

Give it a week before judging. The first version of any prompt file is approximately right, and the useful version is the one that exists after someone has been disappointed by it once and fixed it.

Organising as it grows

Six files need no organisation. Fifteen do, and the two approaches available pull in different directions.

Flat with disciplined naming is what most teams should do. Consistent verb prefixes — review-, generate-, explain- — make a flat list scannable, and a flat list is what the prompt selector shows anyway. The discipline is in the naming, not the structure.

Subdirectories become defensible when a repository genuinely contains separate domains, in a monorepo with a frontend and a data pipeline that share almost no conventions. The cost is that discovery now requires knowing which directory to look in, which is exactly the friction that makes people stop using a library.

The honest advice: if you are reaching for subdirectories, first check whether you have fifteen files because you need fifteen or because nobody has deleted anything. It is usually the second.

The relationship with instructions

These two mechanisms are often discussed as alternatives and they are not.

Instructions are the floor: rules that apply to everything, automatically, on every surface. They are where your team’s non-negotiables live, and they work for the colleague in Eclipse who cannot use a single one of your prompt files.

The library is the convenience layer: focused, opinionated versions of tasks that would be inappropriate to apply universally. “Review exclusively for concurrency bugs and ignore everything else” is a terrible instruction and a good prompt file, because it only runs when someone has decided that is the job.

Building the library first is a common mistake. It produces a set of prompts each of which restates the same conventions, because those conventions have nowhere else to live. Write the instruction file first, and the prompt files get shorter and sharper — each one carrying only what is specific to its task, with the shared rules already in force underneath.

Next

Team coding standards is the capstone: combining instruction files, path-specific rules and this library into something a team owns. Prompt files covers the mechanism in detail, and 100 prompts is raw material — anything there you reach for weekly is a candidate.