Microsoft's APM Puts Your Agent Skills in One apm.yml With a Lockfile. Pin Your Agent Config Like You Pin Dependencies.

Microsoft's APM (Agent Package Manager) is an MIT-licensed tool that lets you declare your agent skills, prompts, instructions, plugins, hooks and MCP servers in one apm.yml file, then installs each to the coding agents you use. Its own docs call it "npm for agent context." If you are copying the same skill folder into Claude Code, Cursor and Codex by hand, this is aimed at you. It is also a direct answer to the Postman plugin story from November 6: if your agent config can change without you noticing, it needs the same controls as your code dependencies.

What it does

You write a manifest with a name, version, targets and a dependency list. Dependencies can be GitHub owner/repo/path entries with an optional #ref pin, or objects pointing at any git host. MCP servers are listed by registry name. apm install then deploys the primitives to the harnesses that support them. The docs name nine: GitHub Copilot, Claude Code, Grok Build, Cursor, OpenCode, Codex, Gemini, Windsurf and Kiro.

Three features matter more than the multi-target convenience:

• A lockfile, apm.lock.yaml, that records resolved sources and content hashes, so a fresh clone gets the same package content byte for byte.
• A hidden-Unicode scan on every install, with apm audit to run it on demand. This targets text that is invisible to you but readable by the agent.
• A block on transitive MCP servers unless you declared or trusted them, plus an apm-policy.yml for install-time rules.

It can also export an SBOM in CycloneDX or SPDX format, which the docs describe as provenance information, not a compliance attestation.

What to be careful about

I could not find a version number or release date on the docs or the README. The docs page shows "Last updated: Oct 22, 2026." The manifest examples are described as a "working-draft contract," and the docs say older published schemas reject the git-plus-path form. Those are signs of a moving target, and that is my reading, not a label the project uses. The repo showed roughly 4.2k stars when I checked a cached snapshot. Popular is not the same as stable.

A package manager for agent instructions also creates a new place for things to go wrong. You are now pulling instruction text from other repos. The lockfile and Unicode scan reduce that risk. They do not read the instructions for you.

How I would trial it

1. Pick one repo, not all of them. Use a throwaway branch.
2. Move two skills you wrote yourself into the manifest. Do not start with third-party packages.
3. Run apm install, then apm audit, and diff what landed in each harness folder against what you had.
4. Commit the lockfile. Then change one upstream skill and confirm the lockfile forces a visible diff.
5. Only after that, add one external dependency, pinned to a tag or commit, and read its text yourself.

The honest take

The idea is right: agent config is code, and code gets pinned, diffed and reviewed. I am less sure the tool is ready to be the only thing standing between you and a bad skill. The schema is still shifting, and I have not run it on a large project. If you only use one harness, a plain git repo with reviewed skill folders already gives you most of the benefit. If you use three or more harnesses, the multi-target deploy is worth a one-repo experiment this week.

Author

Lukas

@lukcombinator

Sources

• APM documentation
• microsoft/apm on GitHub