plugins/creating-prompts/skills/creating-prompts/SKILL.md
Creates GitHub Copilot prompt files (`.prompt.md`) for VS Code. Use when building reusable workflow starters that route work to the right agent, collect the right inputs, and ship with install-ready templates, examples, and validation guidance.
npx skillsauth add jaktestowac/awesome-copilot-for-testers creating-promptsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use this skill when a task deserves a reusable entrypoint instead of the user re-explaining the same workflow every time. It helps create prompt files that are specific, easy to invoke, and well-matched to the agent or workflow behind them.
Use this skill when the user asks for things like:
.prompt.md"Typical scenarios:
A strong prompt contribution usually includes:
Use a prompt when users need a reusable task starter. If the real need is a standing expert role, create an agent. If the real need is reusable procedural knowledge, create a skill. If the real need is always-on repository rules, create instructions.
Clarify or infer:
Choose the smallest useful set of fields:
name for a readable menu label when neededagent to route the workflow intentionallydescription to make the prompt discoverablemodel when a model choice materially mattersargument-hint when the user needs help providing the right contexttools only when the prompt truly needs to override defaultsUse the supporting resources below while drafting:
./resources/prompt.template.prompt.md./resources/prompt.example.prompt.mdA good prompt body should usually include:
At minimum, provide:
.prompt.md fileCheck the result against ./resources/prompt-quality-checklist.md.
Pay special attention to:
description and name./resources/prompt.template.prompt.md - scaffold for a focused prompt file./resources/prompt.example.prompt.md - worked example of a reusable prompt./resources/prompt-quality-checklist.md - final review checklist before shippingA task using this skill is complete when:
testing
Tests the customization assets themselves - skills, prompts, custom agents, instructions - the way a product is tested: activation cases that check an asset fires when it should and stays quiet when it should not, output-contract cases, safety cases, collision cases between assets competing for the same trigger, a weighted rubric scored blind, and a baseline-versus-candidate gate before an edit ships. Use when a skill is edited and nobody knows whether behaviour changed, when two skills fight over the same request, when a description is being tuned for discoverability, when a collection has grown past manual spot-checking, or when the request mentions skill evals, prompt regression, or "does this skill actually work".
development
Shapes QA output for the person who has to act on it: result and blocker in the first two lines, one decision per report, findings ordered by what they cost, the long artifact in a file and the decisions in the message, and magnitude stated in units the reader can count. Use when a report is accurate but nobody acts on it, when a finding set is too long to read under time pressure, when the same findings must be retold for a developer, a release manager, and an on-call engineer, or when the request mentions "too long", "make this readable", "just tell me what to do", "so what", or "summarize this for stakeholders". Pairs with unslop-answers, which makes the same report honest.
testing
Verifies that the lines and branches a change actually touched are executed by tests, using LCOV or Cobertura diff coverage instead of whole-repo percentages, and escalates uncovered high-risk changes into a blocking finding. Use when a pull request needs a coverage gate that unrelated tests cannot satisfy, when total coverage looks healthy but the diff is untested, when wiring diff coverage into CI, or when someone claims a change is covered because the suite is green.
development
Cuts AI tells from test code: tests that pass without proving anything, tautological assertions, mock-only tests, hardcoded waits, coverage theater, vague names, swallowed errors, retries used as fixes. Use whenever test code is written, changed, or reviewed, including tests produced as a side effect of a feature task, and when the request mentions "review these tests", "are these tests any good", "this test always passes", "this suite is flaky", or "clean up these tests". Must always apply to test code.