Most agent advice stops at the demo. These 21 skills carry the part after that: the order to do things in, the questions worth asking before you build, and the failures that only show up once real users arrive.
Plain Markdown, no harness lock-in. If your tool can read a file into context, it can run these.
The agent demos beautifully. Then it goes to real users, and it answers a question three different ways in three sessions, cites a page that does not say what it claims, and nobody can tell you who owns it or what it costs to run.
None of that is a model problem. It is the part of the work that happens after the demo, and it is the part almost nobody writes down. That is what is in here.
One collection, installed once, that your agent reaches into when the task calls for it.
Clone the repo or add it as a plugin. Every skill is a Markdown file, so there is nothing to run and nothing to keep in sync.
Three skills wait to be asked, because an interview that starts itself is worse than no interview. The other eighteen load themselves when the task matches.
A skill is not a prompt. It carries the order to do things in, the questions to ask, and the failure it is written to prevent.
Every claim carries the date it was last checked against Microsoft's docs, and every link is re-tested on a schedule.
Grouped by what you are doing, not by which Microsoft product is involved. Products get renamed, and a skill filed under a renamed product becomes unfindable.
Creating an agent or solution on any Microsoft surface.
Diagnose and fix a Copilot Studio agent that hallucinates, cites the wrong source, or answers inconsistently.
The patterns that separate a Copilot Studio agent that demos well from one that survives production.
Move an existing agent off a monolithic system prompt onto portable, versioned skill files without carrying its rot forward.
Write or repair an agent skill so it fires when it should and stays quiet when it should not.
Wiring an agent to data, systems and tools: connectors, MCP servers, APIs.
Reviewing something that already exists: code, YAML, solutions, architecture, security.
Work out what a Power Platform or Copilot Studio change breaks somewhere else, before it ships.
Measure whether an agent works, and whether it still works, with a recorded eval set.
Review a Copilot Studio agent's YAML for defects that matter before it ships.
ALM, testing, evaluation, governance, monitoring, cost, incident response.
Decide whether an agent should still exist, who owns it, and whether it is governed the way production requires.
Set up the signals that tell you an agent is healthy and being used before a user has to report otherwise.
Work out whether an agent's message capacity, quota or spend is sized correctly before a limit or a bill surprises someone.
Fix and prevent Power Platform solution imports that break on connection references, environment variables and flow ownership.
Triage and recover when a live agent is failing right now and users are affected.
The consulting layer: discovery, estimating, requirements, decisions, handoff.
Work out which skill in this repo fits the situation in front of you.
Work out which Microsoft platform an agent should be built on, and write down why.
Rewrite text that reads like a model wrote it into something a person would send.
A structured interview that pins down what you are actually building before you build it.
Interview the user until every open branch of a plan or design is resolved.
Work out whether this needs an agent at all, and whether to consume, govern or build.
Learning the stack yourself, and teaching it to others.
The difference is not cosmetic. It decides whether the agent may start something on your behalf.
Reachable only when you ask for it by name. Interviews, reviews and anything that should wait to be asked rather than firing on a keyword. An interview that starts itself is worse than no interview.
The agent loads it when the task matches its description. That is why each description is written as a trigger, listing the situations it fires on, rather than as a summary of contents.
Pick your harness. Each skill is the same SKILL.md underneath.
The repo is its own single-plugin marketplace, so registering it and installing from it are two steps. The name appears twice because the plugin and the marketplace that carries it share a name. That is correct, not a typo.
Microsoft Agent Skills
/plugin marketplace add RagnarPitla/microsoft-agent-skills
/plugin install microsoft-agent-skills@microsoft-agent-skillsCopilot reads the Agent Skills open standard natively, the same SKILL.md format this repo is written in, in VS Code, the Copilot CLI and the Copilot cloud agent.
git clone https://github.com/RagnarPitla/microsoft-agent-skills
cp -r microsoft-agent-skills/.github/skills .github/Codex reads the same SKILL.md standard, from <name>/SKILL.md directories under ~/.codex/skills. The generated tree is already in that shape.
git clone https://github.com/RagnarPitla/microsoft-agent-skills
cp -r microsoft-agent-skills/.github/skills/* ~/.codex/skills/Generated rules, ready to copy into a project.
git clone https://github.com/RagnarPitla/microsoft-agent-skills
cp -r microsoft-agent-skills/.cursor/rules .cursor/Using something else? Every skill is plain Markdown at skills/<bucket>/<name>/SKILL.md. Read the file directly, or point your tool at skills/index.json, which lists every skill with its trigger, invocation model and paths.
When Microsoft already solves something well, this repo routes you to them and says so.
registry/microsoft-ecosystem.yaml catalogues the official and community repos worth knowing. registry/connectors.yaml covers how to connect an agent to a given system. Star counts and archive flags are pulled from the GitHub API rather than typed in by hand, so they do not quietly go stale.
Every URL cited anywhere in the repo is re-tested on a schedule, because a link that 404s costs more trust than a missing page. Every dated claim has a review window, and the build fails when one expires.
No. GitHub Copilot is the primary target, and Codex and Cursor are peers rather than afterthoughts. Every skill is plain Markdown with no harness-specific assumptions, so any tool that can read a file into context can run them.
A Markdown file with front matter, holding the method for one job: what to ask, what order to do it in, and what goes wrong if you skip a step. It is closer to a checklist written by someone who has done the work than to a prompt.
Because Microsoft renames its products constantly. A folder called copilot-studio would be wrong within a year, and a skill filed under a renamed product becomes unfindable. Products appear inside a skill, never as the top-level taxonomy.
Every skill records the date its claims were last read against Microsoft's documentation, and one line on where the knowledge came from. Perishable claims carry their own review date and the build fails when one goes stale. Where something could not be verified, the skill says so instead of guessing.
No. Nothing here names a customer, carries data from a customer tenant, or describes anything Microsoft has not announced publicly. Worked examples use invented companies and synthetic data, and a scrub gate runs before anything is published.
Yes. MIT licensed. Fork it, copy one skill out of it, or rewrite them for your own stack.