microsoft/apm is Microsoft’s Agent Package Manager (APM): a manifest-driven way to install and share everything an AI coding agent needs in a repo—skills, MCP servers, plugins, prompts, hooks, and related primitives—so newcomers get a reproducible stack after git clone, not a wiki of manual setup steps.
Primary sources: GitHub — microsoft/apm · Documentation site
This note is a builder-oriented summary of what APM claims to solve, how it compares to ad-hoc npx skills add flows, and where ExplainX readers already have parallel concepts (skills registry, MCP directory).
Quick reference
| Topic | Upstream framing |
|---|---|
| Problem | Agent context (standards, prompts, skills, plugins) is set up per developer; little portability |
| Core artifact | apm.yml — declare dependencies once |
| Reproducibility | apm.lock.yaml — pin resolved tree and integrity |
| Governance | apm-policy.yml — org allowlists and enforcement |
| License | MIT (per repo) |
| Repo signals | On the order of ~2.1k stars and ~150 forks in public listings—verify live stats on GitHub |
Treat versioned behavior against the release you install; the project ships tagged releases (for example v0.10.x in recent history).
Mental model: package.json, but for agents
APM’s pitch is deliberately familiar:
- You declare dependencies in
apm.yml - You
apm installto materialize files and wire supported clients - Transitive packages resolve like npm/pip-style trees
- A lockfile records what was actually resolved
That matters because agent “dependencies” are not just libraries—they are instructions and tool wiring that change model behavior. Treating them like versioned supply chain is closer to how security teams already think about code.
Example manifest shape (from upstream README)
The README illustrates apm.yml mixing APM-packaged skills, plugins, agent markdown, full packages, and MCP servers:
name: your-project
version: 1.0.0
dependencies:
apm:
- anthropics/skills/skills/frontend-design
- github/awesome-copilot/plugins/context-engineering
- github/awesome-copilot/agents/api-architect.agent.md
- microsoft/apm-sample-package#v1.0.0
mcp:
- name: io.github.github/github-mcp-server
transport: http
After clone:
apm install
Upstream positions this as one command to align Copilot, Claude, Cursor, OpenCode, Codex, and Gemini installs—with client-specific caveats called out in docs (notably around MCP transports and Codex).
“Coming from npx skills add?”
The README now includes an explicit conversion block. The idea:
apm install vercel-labs/agent-skills
apm install vercel-labs/agent-skills --skill deploy-to-vercel
Same install gesture, plus you keep a manifest, lockfile, and policy hooks if your org adopts them.
On ExplainX, many teams still discover skills through the registry UI; APM is complementary infrastructure for repo-first workflows. Start with our agent skills guide if the vocabulary is new.
Security and governance (what enterprises will care about)
APM’s README groups value into portability, secure defaults, and governance. Under the security column, it highlights:
- Reproducibility — manifest + lockfile with hashed resolution
- Install-time checks — scanning for content that can subvert agent parsing (upstream cites hidden Unicode-style risks)
- MCP trust — transitive MCP installs gated behind explicit consent
- Policy hooks —
apm-policy.ymlfor allowlists and inheritance patterns, plus CI audit integration (for example branch protection workflows)
None of that removes the need for human review on high-risk repos; it raises the floor. For threat framing, see agent skills security.
Installation (official scripts)
Upstream documents:
Linux / macOS
curl -sSL https://aka.ms/apm-unix | sh
Windows
irm https://aka.ms/apm-windows | iex
Then add packages (apm install ...), marketplaces, or MCP targets (apm install --mcp ...). Always read Microsoft’s Getting Started on microsoft.github.io/apm before running remote installers in regulated environments.
agentrc and shared instruction formats
The README ties APM to agentrc: generate repo-grounded instructions from code, then package them for org-wide reuse. The .instructions.md format is called out as shared—useful when you want mechanical truth (build commands, conventions) combined with curated skills from publishers you trust.
How this fits ExplainX’s broader map
| Piece | Role |
|---|---|
| Agent skills | Portable playbooks—often SKILL.md trees |
| APM | Install and lock those playbooks (and more) per repo |
| MCP | Runtime tools and data—APM can declare MCP deps; concepts in MCP guide |
| Registry | Browse skills and MCP servers for discovery—APM is how you might vendor those choices into git |
Vendor skill bundles such as google/skills are exactly the kind of upstream you might pin by version once APM’s resolution story matches your compliance needs.
Bottom line
microsoft/apm is Microsoft’s bet that agent configuration deserves the same tooling gravity as application dependencies: declarative manifests, lockfiles, policy, and multi-client install. If your team is outgrowing one-off npx skills add notes in Slack, APM is worth evaluating as repo-standard infrastructure—then prove it in CI with apm audit-style gates your security team can read.
Product behaviors and client compatibility change by release; verify against microsoft.github.io/apm and the repository. ExplainX is not affiliated with Microsoft. Repository star and fork counts are approximate; check GitHub for current metrics.