skills/creating-custom-agents/SKILL.md
Creates GitHub Copilot custom agents (`.agent.md`) for VS Code. Use when defining a specialized agent role, selecting a minimal toolset, referencing supporting skills, or shipping install-ready agent examples with clear boundaries and collaboration rules.
npx skillsauth add jaktestowac/awesome-copilot-for-testers creating-custom-agentsInstall 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 reusable role needs its own identity instead of hiding inside a prompt or a skill. It helps create custom agents that are focused, tool-aware, and easy to extend without scope creep.
Use this skill when the user asks for things like:
.agent.md file"Typical scenarios:
A strong custom agent contribution usually includes:
.agent.md file plus reference materialChoose an agent only when the work needs a persistent role, a specific tool profile, or a distinct collaboration pattern. If the need is only a reusable task starter, prefer a prompt. If the need is procedural knowledge, prefer a skill.
Before drafting:
Clarify or infer:
.agent.md fileUse the supporting files below while drafting:
./resources/custom-agent.template.agent.md./resources/custom-agent.example.agent.mdA good first draft should cover:
At minimum, provide:
.agent.md fileIf the agent is part of a larger workflow, mention the prompts or skills it should work with.
Check the result against ./resources/custom-agent-quality-checklist.md.
Pay special attention to:
./resources/custom-agent.template.agent.md - scaffold for a focused custom agent./resources/custom-agent.example.agent.md - worked example of a bounded specialist agent./resources/custom-agent-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.