Copilot Prompt Gallery: community prompts and skills for Microsoft Copilot

A gallery of three different kinds of artefact

The repository describes itself as the Copilot Prompt Gallery, hosted at pnp.github.io/copilot-prompts/. The stated purpose is that the gallery is the primary way to discover, search, filter and download the community's prompts, agent instructions and reusable skills for Microsoft 365 Copilot, Microsoft Copilot and GitHub Copilot.

The three sample types are distinct, and the table in the documentation makes the difference clear.

A prompt lives in samples/prompts/{folder-name}/ and is a reusable instruction for a focused task or outcome. An agent instruction lives in samples/agent-instructions/{folder-name}/ and defines an agent's role, process, tone and boundaries. A skill lives in samples/skills/{folder-name}/ and is a SKILL.md package that teaches GitHub Copilot a repeatable multi-step task.

The counts are stated in the documentation with a marker comment around them, suggesting they are regenerated rather than typed. The gallery holds 119 prompt samples, 31 agent instructions and 10 skills.

That ratio is the interesting signal. The overwhelming majority of the collection is single-purpose instructions, with a smaller set of role-defining agent instructions and a much smaller set of multi-step skills. The directory layout also suggests that each sample is self-contained, since every one includes a canonical README.md and an assets/sample.json, and skills additionally include SKILL.md against a separate SKILL-SCHEMA.md specification.

The project is a community effort maintained by volunteers in the Microsoft 365 and Power Platform Community, and the documentation is explicit that the samples are provided as-is, are not Microsoft products, and do not include official Microsoft support or a service-level agreement. That sentence is the most important line on the page for anyone planning to build on it.

What each sample page gives you before you download

The find and use a sample section explains what the gallery offers on each sample page, and it is more than a preview.

Each page provides a representative preview and a concise description, product, contributor, creation and update metadata, the contributor's own setup, prerequisites and usage documentation, and links to view the source or download the sample.

The third of those is the part that separates this from a list of prompt text on a wiki. A prompt is only half the artefact. The other half is knowing which Copilot feature it is meant for, what has to be switched on first, whether it needs a specific licence, and what the contributor actually tested it against. Shipping a prompt without that context is how a team ends up with a file that does nothing in their tenant.

The metadata fields also make the collection auditable. Contributor and update dates tell you how stale a sample might be, and the product field tells you whether it targets Microsoft 365 Copilot, Microsoft Copilot or GitHub Copilot, which have different capabilities and different configuration surfaces.

The documentation's advice is to review the sample-specific documentation before use, and it gives the reason plainly. Prompts and instructions can produce incomplete or inaccurate results, and requirements differ between Copilot products, tenants, licences and organisational policies. The instruction is to validate and adapt every sample for your own security, privacy, compliance and governance requirements.

That last sentence is where a prompt stops being a demonstration and becomes a piece of your environment. A prompt that asks for a summary of an email thread is harmless in a demo and a data handling question in a regulated tenant, and the gallery is telling you that judgement is yours to make.

The source files remain available under the samples directory for contributors and advanced users, so anything in the gallery can be read and copied without going through the site.

The gallery is a static build that reads the samples

The gallery development section explains that the static Astro gallery reads every sample's assets/sample.json and README.md during the build, and that Node.js 22.19.0 or newer is required.

cd site
npm ci
npm run dev

So the architecture is a build-time aggregation. The sample directory is the source of truth and the site is generated from it. There is no database and no server-side component, which is why it can be published to GitHub Pages by the deployment workflow in .github/workflows/deploy-site.yml.

The consequence for contributors is that a sample that does not include a valid assets/sample.json or a README.md will not appear correctly in the gallery. The scripts directory at the root exists for that kind of tooling, and the documentation asks you to run checks before submitting gallery changes.

npm run validate:readme-trackers
npm run build
npm run test:e2e

The validation step, the build and an end to end test run. The presence of a dedicated readme tracker validation suggests the repository has scripts that keep documentation in sync across samples, and that the maintainers have had to solve the drift problem that comes with a hundred and twenty separate contributor-owned directories.

The primary language of the repository is listed as Astro, which reflects that the site is the dominant code artefact here. The samples themselves are documentation and configuration, so the interesting engineering is in the gallery tooling and in the sample schema rather than in application code.

Contributing, and the scaffolding Copilot provides

The contribution section is unusually practical, and it starts by telling you not to duplicate work.

The first step is to search the gallery and the existing issues to avoid duplicate work, then read the contribution guidance in CONTRIBUTING.md, then keep each pull request focused on one sample or one logical change.

Then there is the part worth noting. GitHub Copilot can scaffold all three contribution types in VS Code, with the options to create a new prompt sample, create an agent instruction, or create a new skill sample.

That is a neat loop. A repository that collects prompts for an AI coding assistant uses that same assistant to help write more of them, in the editor the samples are written for. Contributors are recognised with the Prompt Pro Microsoft 365 and Power Platform Community Credly badge, and the documentation explains how community recognition badges are issued and shared.

There is a permissions note attached to contributing that is easy to miss. By contributing, you also permit the community to display the GitHub avatar listed in your sample metadata on the gallery and in community recognition posts, and to use a different image or opt out of promotional posts you contact the maintainers through a repository issue.

So contributing a sample also publishes your avatar in a place you may not have expected. That is a reasonable default for a public community gallery, and it is documented, but it is the kind of thing a corporate contributor should check against their own policies before opening a pull request.

Support routing and the boundary the project will not cross

The support and issue routing section draws lines between what the repository can help with and what it cannot, and the lines are drawn in the right places.

For a problem with a specific community sample, the instruction is to first review that sample's documentation, then search or open a GitHub issue. For a new sample idea or a gallery improvement, use the matching issue form. For general Microsoft Copilot product, licensing, tenant or service questions, use official Microsoft documentation, your Microsoft support channel, or the relevant product community, and the documentation states that this repository cannot provide product support.

For suspected security vulnerabilities, the instruction is to follow SECURITY.md and not to disclose sensitive details in a public issue.

That last one is the section to read first if you are evaluating the project for anything security sensitive. The repository has a SECURITY.md, which is the difference between a project that has a disclosure process and one that does not.

The overall support posture is stated once more at the end of the section: assistance from maintainers and contributors is voluntary and provided on a best-effort basis, with the policy in SUPPORT.md.

The disclaimer reinforces the same point in the formal language. Samples and documentation are provided as-is without warranty of any kind, express or implied, including warranties of fitness for a particular purpose, merchantability or non-infringement.

The resources list points at the official Microsoft Copilot documentation, the Microsoft 365 Copilot documentation and the GitHub Copilot documentation, which is the correct place to go for anything about the products themselves. What this repository holds is the community's examples, and it is careful to say that the two are different things.

Where the gallery is the wrong thing to reach for

There are two clear cases.

The first is when the requirement is a supported artefact. If a prompt or an agent instruction is going into a production workflow with a compliance obligation attached, a community sample with an as-is disclaimer and a best-effort support policy is the wrong foundation, whatever the prompt itself contains. The support policy is not a formality in that context: it decides who you call when the behaviour changes after a Copilot update, and the answer here is that nobody is contractually obliged to help.

The second is when you need behaviour that is guaranteed to work across a product update. Prompts are sensitive to model and product changes in ways that ordinary code is not. The documentation says outright that prompts and instructions can produce incomplete or inaccurate results, and that requirements differ between Copilot products, tenants, licences and organisational policies. A gallery sample is a snapshot of what worked for one contributor on one setup.

There is a third, quieter consideration. A hundred and nineteen prompts is a large surface for the mistakes that prompt text invites. A prompt that tells an agent to summarise a folder, or to follow a link, or to include an attachment, encodes an assumption about what the agent will do with the result, and the person who wrote it had that assumption in their head. Adopting a gallery prompt means adopting someone else's assumption without their context, and the gallery's per-sample documentation is where that context lives, which means the gallery is only as good as the documentation contributors chose to write.

The alternative approaches split along the same line. Writing your own instruction file costs an afternoon and gives you exactly the behaviour you want, with no assumption gap and no dependency on a maintainer. Installing a skill from a vendor or an internal source gives you a supported artefact with a named owner. And using the gallery for what it is good at, as a source of patterns and phrasing that you adapt and test in your own tenant, captures the value without the liability.

Editorial conclusion

The Copilot Prompt Gallery suits a Microsoft 365 or GitHub Copilot user who wants a starting point for an instruction file or a skill package rather than writing one from scratch, and its per-sample documentation on prerequisites and setup is what makes it usable rather than merely browsable. It does not suit anyone who needs a supported or guaranteed artefact, because the repository states plainly that the samples are community contributions without official support, and a prompt carries no contractual commitment. Before adopting a sample, read that sample's own documentation and validate it against your own tenant and licensing, since the gallery itself warns that results can be incomplete or inaccurate and that requirements differ between Copilot products, tenants, licences and organisational policies.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pnp/copilot-prompts on GitHub
4. Project website
5. README