microsoft/skills: Agent Skills for Azure SDK and Foundry Work

The gap microsoft/skills fills is activation context, not model knowledge

The README makes an argument that is easy to miss among the skill tables: coding agents already carry the Azure SDK patterns in their weights from pretraining, and what they lack is the right activation context to surface them. That framing matters because it tells you what this repository is not. It is not a code generator, a runtime, or a package your application imports. It is a collection of markdown skill definitions, custom agent definitions, AGENTS.md templates and MCP server configurations that get placed into an agent's configuration directory so the agent retrieves the relevant pattern when a task touches Cosmos DB, Foundry model deployment, or an MCP server build. The intended audience is narrow and specific: engineers using Copilot CLI or GitHub Copilot in VS Code who work against Azure SDKs and Microsoft AI Foundry. If your daily work is a Django app on Postgres with no Azure surface, the catalog has little to offer you, and the README's own warning about context rot applies with full force.

How skills are laid out and what the suffix convention encodes

The repository organizes skills by language, and the naming convention is the routing mechanism. Python skills carry a `-py` suffix, .NET uses `-dotnet`, TypeScript uses `-ts`, Java uses `-java`, and Rust uses `-rust`. Core skills and Foundry skills have no suffix because they are language-agnostic. The README gives counts of 11 core skills, 11 Foundry skills, 39 Python, 28 .NET, 25 TypeScript, 25 Java and 7 Rust, which sums to 146 while the page elsewhere advertises 175 skills and 174 skills in two different places. That inconsistency is visible in the material and worth noting rather than resolving: the catalog is growing, and the headline number has not been reconciled with the per-language table. The Foundry skills live under a plugin path, `.github/plugins/azure-skills/skills/`, rather than directly under `.github/skills/`, which suggests the plugin packaging is a separate distribution layer from the flat skill directory. The `microsoft-foundry` skill is described as a router: it maps user intent onto the right sub-skill and discovery surface, which is a different pattern from a leaf skill that carries domain content.

Installation runs through a wizard, and the wizard decides your directory

The primary install path is a single command: `npx skills add microsoft/skills`. The README states that you select the skills you need from the wizard, and that skills are installed to your chosen agent's directory, with `.github/skills/` given as the example for GitHub Copilot. It also states that skills are symlinked if you use multiple agents. For manual installation the README gives `git clone https://github.com/microsoft/skills.git` followed by a copy of a specific skill directory, for example `cp -r agent-skills/.github/skills/azure-cosmos-db-py your-project/.github/skills/`. Note that the clone command produces a directory named after the repository while the copy path assumes `agent-skills/`, so the manual instructions do not line up exactly; you will need to adjust the path. The README also shows symlinking a shared skills directory into multiple agent configs, `ln -s ../.github/skills .opencode/skills` and `ln -s ../.github/skills .claude/skills`, which is the practical answer for a repository where more than one agent reads the same skills. There is a `skills.sh` install badge pointing at `https://skills.sh/microsoft/skills`, so a second distribution channel exists alongside the npx wizard.

Context rot is the limitation the project itself names first

The README carries an explicit warning block: use skills selectively, because loading all skills causes context rot, described as diluted attention, wasted tokens and conflated patterns. This is the most useful sentence in the document for anyone deciding whether to adopt. A repository that ships 175 skills is not a repository you install wholesale. The failure mode is concrete: an agent with 175 skill descriptions in context has to choose among them on every turn, and the README's own position is that this degrades output. The second limitation is the work-in-progress notice, which states that more skills are being added, that existing skills are being updated to use the latest SDK patterns, and that tests are being expanded. There are no releases retrieved for this repository, so there is no version number to pin against and no changelog to read when a skill's guidance changes. If you vendor skills by copying them into your project, you inherit the update problem: you have to re-copy to get SDK pattern fixes, and you have no signal telling you when that is needed.

What the repository bundles beyond skills

Skills are the bulk of the catalog, but the README lists four other resource types. Custom agents are role-specific and the README names four: backend, frontend, infrastructure and planner. An AGENTS.md file at the repository root serves as a template for configuring agent behavior in your own projects. MCP configurations are described as pre-configured servers for docs, GitHub and browser automation. Plugins are installable packages, with `deep-wiki` and `azure` named as examples. The Foundry skill set leans on MCP heavily: the `microsoft-foundry` router skill is documented as mapping intent onto discovery surfaces including Microsoft Docs MCP, Foundry MCP, the `azd ai agent` command and the `az` CLI. That means the Foundry skills assume those tools are present and authenticated, which is a real prerequisite rather than a detail. The `mcp-builder` skill covers building MCP servers in Python with FastMCP, in Node or TypeScript, or in C# and .NET, so the repository both consumes MCP servers and teaches you to write them.

Where it sits relative to a general-purpose agent prompt library

The obvious alternative is a general prompt or rules collection, the kind of repository that hands an agent a style guide and a set of coding conventions. The difference in approach is scope and specificity. A general rules file tells the agent how your team writes code across every language and framework; a skill in this repository tells the agent how to do one thing in one SDK, and it is retrieved only when the task matches. The trade-off runs both ways. General rules are cheap to maintain because there is one file and it changes rarely. Skills are numerous, individually small, and each one is a maintenance surface that tracks an SDK. The README's claim that the patterns are already in the model's weights and only need activation context is the strongest argument for the skill approach: you are not teaching the model Azure, you are reminding it which Azure pattern applies. A second alternative is to write your own skill definitions using the `skill-creator` skill, which the catalog includes. That is the right move if your internal conventions diverge from Microsoft's published patterns, since a forked skill will drift from upstream SDK changes.

Licence, maintenance and what to check before you commit

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive enough for vendoring skills into a private repository, but if you copy skill text into your own project, the MIT notice needs to travel with it. This is a description of the licence terms, not legal advice; if the skills end up in a distributed product, have counsel look at the notice requirements. On maintenance: the repository is not archived, the last push recorded is 2026-09-10, and the README states the project is under active development with contributions welcome. The cost of adoption is therefore ongoing rather than one-time. Every SDK pattern update upstream is a skill update you either take (and re-verify against your code) or skip (and drift from current guidance). The repository has no releases, so there is no upgrade command and no version boundary. The practical mitigation is to pin a commit hash when you vendor, and to re-check the specific skill directories you use rather than pulling the whole tree. The CI badges reference a test harness workflow and a Copilot SDK test workflow, which indicates the skills are exercised, though the README does not describe what those workflows assert.

Editorial conclusion

Adopt it if your team writes Azure SDK or Foundry code with Copilot CLI or Copilot in VS Code and wants the SDK patterns surfaced without pasting them into every prompt. Skip it if you do not work in that stack, or if you need a stable interface: the README labels the repository a work in progress, and skills are still being updated to newer SDK patterns. Before installing, read the source of the two or three skills you actually need under .github/skills/, check which SDK version each targets, and verify the install path the wizard picks for your agent. The repository is a context library with no versioned releases, so pin a commit if reproducibility matters.

Official sources

1. Issues
2. License: MIT
3. microsoft/skills on GitHub
4. Project website
5. README