plugins/creating-skills/skills/creating-skills/SKILL.md
Creates GitHub Copilot skills with reusable workflows, companion resources, and validation gates. Use when packaging repeatable expertise into a `SKILL.md` folder, deciding what belongs in the skill body versus resources, or producing install-ready skill examples for a team or collection.
npx skillsauth add jaktestowac/awesome-copilot-for-testers creating-skillsInstall 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 reusable know-how deserves a home of its own instead of living in prompts or chat history. It helps create skills that are discoverable, concise, and bundled with the right supporting assets.
Use this skill when the user asks for things like:
SKILL.md"Typical scenarios:
SKILL.md into a leaner body plus resource filesA strong skill contribution usually includes:
SKILL.md body that teaches a workflow, not a personaresources/.Clarify or infer:
Before writing:
Plan the folder contents before drafting:
SKILL.md for the activation and workflow logicresources/ for templates, examples, decision guides, or checklistsDefault to a small bundle first. Add more files only when they remove ambiguity or repetition.
SKILL.mdMake the main file do the high-value work:
Use these support files when building the folder:
./resources/SKILL.template.md./resources/SKILL.example.md./resources/skill-quality-checklist.mdAt minimum, include:
Check the final result against ./resources/skill-quality-checklist.md.
Pay special attention to:
playwright or security as the entire skill name./resources/SKILL.template.md - base scaffold for the main skill file./resources/SKILL.example.md - complete example of a compact, user-invocable skill./resources/skill-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.