microsoft/skills: Agent Skills for Azure SDK and Foundry Coding Agents

The problem microsoft/skills solves for Azure SDK work

Coding agents already know the shape of Azure SDK code. The README makes this argument directly: the patterns are in the model weights from pretraining, and what is missing is the right activation context to surface them. That gap shows up as code that compiles against an older SDK generation, uses a connection-string pattern where managed identity is now expected, or invents a client constructor that no longer exists.

The target user is narrow. You are building with Azure SDKs or Microsoft Foundry, you drive a coding agent such as Copilot CLI or GitHub Copilot in VS Code, and you want the agent to follow current conventions without pasting documentation into every prompt. The repository also carries non-Azure material, including frontend design review and a podcast generation skill, but the catalog is organized around Azure and Foundry first.

How the skill catalog is organized across languages

The repository splits its catalog by language and by platform. Core holds 11 language-agnostic skills covering tooling and infrastructure, including cloud-solution-architect, mcp-builder, skill-creator and copilot-sdk. Foundry holds 11 more that target the Foundry agent platform through azd, the az CLI and Foundry MCP; the microsoft-foundry entry is described as a router skill that maps user intent onto the right sub-skill and discovery surface.

The language plugins are where the counts get large. Python carries 39 skills with a -py suffix, .NET carries 28 with -dotnet, TypeScript 25 with -ts, Java 25 with -java, and Rust 7 with -rust. The naming convention matters in practice: azure-cosmos-db-py is the Python variant, and the suffix tells you which language a skill assumes before you open it.

Alongside the skills, the repository ships custom agents with roles such as backend, frontend, infrastructure and planner, an AGENTS.md template for configuring agent behavior, and MCP configurations for docs, GitHub and browser automation. The top-level layout reflects this: .github/ holds the skills, docs-site/ holds the published explorer, and hooks/ and tests/ carry the harness.

Installing microsoft/skills and running a first skill

The README gives a single wizard command. It presents a selection prompt, then writes the chosen skills into your agent's directory, for example .github/skills/ for GitHub Copilot, and symlinks them when you use more than one agent.

npx skills add microsoft/skills

After the wizard finishes, the skills you picked appear as directories under your agent's skills folder. If you prefer to control placement, the README documents a manual route: clone the repository and copy a single skill directory into your project.

git clone https://github.com/microsoft/skills.git
cp -r agent-skills/.github/skills/azure-cosmos-db-py your-project/.github/skills/

For a repository that drives several agents, the README suggests symlinks rather than copies, and shows linking one skills directory into other agent config folders so all of them read the same files.

ln -s ../.github/skills .opencode/skills
ln -s ../.github/skills .claude/skills

A first real use is to install one skill that matches the SDK you are already writing against, then ask your agent for a small piece of code in that domain. If the skill is active, the generated code should follow the SDK patterns the skill file describes rather than the older generation the model would otherwise default to.

The context rot warning is the design constraint, not a footnote

The README marks a block as important and tells you to use skills selectively, because loading all skills causes context rot: diluted attention, wasted tokens and conflated patterns. That is an unusual thing for a catalog of 175 entries to say about itself, and it should shape how you install.

The practical consequence is that the install wizard's default posture of picking what looks relevant is the wrong instinct. A skill for a language you are not using, or for a service you are not calling, is not free. It occupies context and competes with the skills that do apply. If your project spans Python and TypeScript, the -py and -ts variants for the same service are two separate directories, and pulling both in when you only write one language works against the mechanism the repository is built on.

The repository's own structure supports a narrower approach. Because skills are plain directories under .github/skills/, you can copy or link exactly the set you want instead of going through the wizard's list.

Where microsoft/skills is the wrong tool

The repository is explicit that it is a work in progress. The README states that more skills are being added, existing skills are being updated to use the latest SDK patterns, and tests are being expanded. A skill file is a snapshot of an API surface at the time it was written, and nothing in the README describes a versioning scheme that pins a skill to a specific SDK release.

That creates a concrete failure mode. If you install a skill written against one SDK generation and your project pins a different one, the agent will confidently emit calls that do not match your dependency. The skill makes the agent more specific, not more correct, and specificity in the wrong direction is worse than a general answer you would have checked anyway.

The second boundary is domain. If your work is not Azure or Foundry related, the catalog's center of gravity does not apply to you. The Core and Foundry groups are built around azd, the az CLI, Foundry MCP and the Azure SDKs. The handful of unrelated skills, such as frontend-design-review or github-issue-creator, are useful on their own but are not a reason to adopt the repository.

How this differs from a general-purpose prompt or rules file

The closest alternative is not another skill catalog. It is the AGENTS.md or rules file you already keep in the repository. That file is one document applied to every task, and it works well for conventions that apply everywhere: formatting, test commands, directory layout.

microsoft/skills takes the opposite approach. It splits knowledge into many small directories that are loaded per task, and it ships an AGENTS.md template as one component among several rather than as the whole mechanism. The difference is granularity. A rules file that describes every Azure service you touch grows until it competes with the code you are asking about. A skill directory for one service can be added and removed independently.

The trade-off runs the other way too. A single rules file is one thing to review and one thing to keep current. A set of skill directories is many, each with its own accuracy to verify, and the README's update note implies that verification is ongoing work rather than a finished state.

Licence, maintenance and what an upgrade costs you

The repository is MIT licensed, which permits commercial use and modification with the licence and copyright notice retained. Nothing in the README discusses attribution requirements for generated code, and this is not legal advice; if you redistribute skill content inside a product, read the LICENSE file at the repository root rather than relying on the licence identifier alone.

The last push to the default branch was on 2026-09-10, and the repository is not archived. The README's work-in-progress note means the upgrade path is not a version bump. There are no retrieved releases, so there is no changelog to diff against. Upgrading means re-running the installer or re-copying directories and then reading what changed in the skills you actually use.

That cost is real if you have edited a skill to match your own SDK version. A copy under your project's .github/skills/ will not receive upstream updates, and the README's symlink guidance cuts both ways: links stay current but also change under you. Decide per skill whether you want a copy you control or a link that tracks the repository.

Editorial conclusion

Adopt microsoft/skills if your coding agent already writes Azure SDK or Foundry code and keeps producing plausible but stale patterns; the skill files are the cheapest way to inject current SDK conventions. Skip it if your work is not Azure or Foundry adjacent, or if you would install the whole catalog at once, since the README states that loading all skills causes context rot. Before relying on any single skill, open its directory under .github/skills/ and check the SDK version and API surface it describes against the SDK you actually installed, because the repository is a work in progress and the README notes existing skills are still being updated to the latest SDK patterns.

Frequently asked questions

Official sources

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