Every function in your company is now writing AI skills. Engineering hand-crafts CLAUDE.md files. Sales builds prompt libraries in Notion. Legal has contract review flows configured in Copilot. Finance keeps reconciliation agents somewhere in a shared drive. Almost none of it is in version control. None of it is reviewed before it ships. Most of it leaves the company when the person who wrote it does.
This is shadow IT's 2020s sequel. The first round was unsanctioned SaaS: Dropbox accounts, Zapier workflows, and Airtable bases scattered across teams. IT eventually got a handle on it through policy, SSO, and procurement. This round is harder. Skills and prompts are closer to institutional knowledge than to tooling. They encode how your company thinks, reasons, and responds. Most companies have no clear picture of where theirs live, who wrote them, or which vendor they are locked into.
Software teams solved a version of this problem a long time ago. We have package managers for everything. npm for JavaScript. pip for Python. cargo for Rust. Dependencies get declared, versioned, shared, and audited. That is the model AI configuration needs, applied across every team now quietly building on top of AI tools.
That's the problem APM (Agent Package Manager) sets out to solve. It's an open-source project hosted under Microsoft's OSS org, created and maintained by Daniel Meppiel. It is a fairly good first attempt at a real problem. It is not the last word.
It's a wild west, and it's bigger than coding
The easy framing is that this is a developer tooling problem. Claude Code users hand-crafting CLAUDE.md. Copilot users hunting skills on GitHub. Cursor users copy-pasting rules from blog posts. MCP servers wired up by whoever had the patience. That framing is real, but it understates the scope.
Over the past year I have watched the same pattern spread across functions that have nothing to do with engineering. Product managers building research agents. Sales teams building proposal generators. Finance teams building reconciliation helpers. Ops teams building runbook assistants. Legal teams building contract review flows. Every one of them is writing skills, prompts, and tool configurations. Almost none of them are in version control. Most are in Slack threads, Notion pages, or a shared Google Doc that three people have accidentally created four versions of.
This is the real scope of the sprawl. AI-native work is not an engineering practice anymore. It has spread across every function that touches knowledge work, and the tooling for managing it has not caught up. There is no accepted pattern for versioning a skill. No review flow for changing one. No agreed way to understand the diff between two prompts that look similar but behave differently. No clean path to hand a skill from the legal team to the sales team without both sides copy-pasting it into the wrong tool.
It is a wild west. And the longer it stays that way, the more expensive it becomes to unwind.
The vendor angle makes it worse. A skill that captures how your company thinks about, say, customer escalation is not a Claude asset or a Copilot asset. It is a company asset. You will want it working in Claude this quarter and in whatever comes next year. If your configurations are locked into a single vendor's format, you have baked a migration cost into every platform decision you will ever make. Multiply that by every skill across every function and the accumulated lock-in gets expensive fast.
That is the problem worth solving. Not just "developers want a nicer way to share CLAUDE.md files." The real question is how companies version, review, compose, and port the institutional knowledge they are encoding into AI tooling right now.
What APM does
APM introduces a simple idea: declare your agent's capabilities the same way you declare your app's dependencies.
name: my-project
version: 1.0.0
dependencies:
apm:
- thinkjones/awesome-apm-stacks/code-core
- thinkjones/awesome-apm-stacks/code-python
- thinkjones/awesome-apm-stacks/ai-agentsRun apm install and it resolves those packages, then deploys them natively into .claude/, .github/, .cursor/, and .opencode/, the directories Claude Code, Copilot, Cursor, and OpenCode already read from. For tools that consume a single instructions file (Codex, Gemini), apm compile generates an AGENTS.md they can pick up.
That last part is the one that matters. One universal format for storing skills, agents, tools, and MCP servers, compiled out to whatever your agent of choice needs. Write your setup once. Deploy it to Claude Code today, Copilot tomorrow, whatever comes next.
Composable by concern
I built awesome-apm-stacks as a curated registry of APM packages, organized by concern:
user-core: context engineering, verification, research, prompt craft, task automation. Install globally, applies everywhere.code-python,code-go,code-typescript: language-specific skills, MCP servers, and best practices.architect-devops: Docker, CI/CD, Terraform, incident triage.security-core: OWASP, vulnerability scanning, agent safety guardrails.plan-core: PRD generation, requirements, QA planning.
Twenty packages total, each independent. A fullstack SaaS project might compose ten of them. A Python agent project might need seven. You pick what you need. No bloat.
For a B2B SaaS team running a typical TypeScript plus Python stack, the manifest tends to look something like this:
dependencies:
apm:
- thinkjones/awesome-apm-stacks/user-core
- thinkjones/awesome-apm-stacks/code-core
- thinkjones/awesome-apm-stacks/code-typescript
- thinkjones/awesome-apm-stacks/code-python
- thinkjones/awesome-apm-stacks/architect-devops
- thinkjones/awesome-apm-stacks/security-core
- thinkjones/awesome-apm-stacks/plan-coreCheck that into the repo and every engineer on the team gets the same baseline on day one. Swap in code-go and architect-mlops if the stack is different.
Wrapping what's already out there
The best skills in the wild are not APM packages. They are SKILL.md files in someone's monorepo, prompt files in a dotfile repo, or chunks of Markdown inside anthropics/skills. Expecting the community to rewrite all of that into a single format would have stalled APM before it started.
APM handles this directly. You can point apm.yml at a subdirectory of any git repo and APM will pull it, place it correctly, and pin it to a commit. Single files work the same way. You can install one prompt from one repo, one skill from another, and a full APM package from a third, all resolved in the same manifest.
That is how awesome-apm-stacks works under the hood. Most of what it ships is not custom. It is wrappers around curated skills from obra/superpowers, anthropics/skills, github/awesome-copilot, and others, composed into stacks organized by concern. The original authors do not need to know APM exists. Their repos work as-is. APM gives you the packaging, versioning, and composition layer on top.
For skill authors: retrofit your repo in three commands
If you already maintain a skills repo, the cleaner path is to make the repo itself APM-compliant rather than relying on a wrapper package in the middle. Your users get native install, you get first-class placement in the registry.
Microsoft's APM ships an apm init command, but it is deliberately minimal. It drops a stub manifest without looking at what is already in your repo. The ai-tooling package in awesome-apm-stacks fills that gap. The apm-retrofit skill walks your repo, classifies every SKILL.md, plugin.json, AGENTS.md, MCP manifest, hook, command, and sub-agent it finds, then proposes a correctly-shaped apm.yml for you to review.
1. Install APM. One line, works on macOS, Linux, and Windows.
$ curl -sSL https://aka.ms/apm-unix | sh2. Install the skill. Pull the ai-tooling package globally so every project on your machine can use the apm-retrofit skill.
$ apm install -g thinkjones/awesome-apm-stacks/ai-tooling3. Retrofit your repo. From inside your skills repo, invoke the skill. It inventories every primitive, proposes an apm.yml, and dry-runs the result before you commit.
> /apm-retrofit
✓ found 4 primitives
✓ wrote apm.yml
✓ apm install --dry-run OKWhat the skill actually does: it inventories primitives from every layout APM recognises, including root SKILL.md, skills/*/SKILL.md, .claude/, .github/plugin/, .cursor-plugin/, .mcp.json, hooks.json, commands/, agents/, AGENTS.md, and CLAUDE.md. It auto-detects target: from the directories present, infers type: from the primitive mix, and derives name, version, and description from existing signals. It never invents values.
Before writing, it diffs against any existing apm.yml and asks for confirmation. After writing, it validates with apm install --dry-run. It never deletes existing files. It never pushes anything.
If you maintain a skills repo, please consider running it. Every repo that goes native makes the registry stronger and reduces the amount of wrapper glue the ecosystem has to maintain.
Why this matters for teams
The real payoff is not for solo developers. It is for teams. When a senior engineer discovers that a particular combination of TDD hooks, security agents, and code review skills produces better output, that knowledge should be packageable. With APM it is. Check an apm.yml into the repo and every developer gets the same agent capabilities on day one.
New hire onboarding goes from "here's a wiki page about how to set up your AI tools" to apm install.
This matters more than it sounds. DX research consistently finds that developer experience variance inside a team is one of the strongest predictors of delivery throughput. When every engineer is running a different agent setup, variance is being baked in at the tooling layer, below the code, below the process. APM collapses that variance without flattening autonomy. Teams still compose their own stacks. What goes away is the drift.
The gap APM does not close
APM solves packaging. It does not solve the social side of version control for people who are not engineers.
If you are a product manager or a legal ops lead who has just built a genuinely useful skill, the expectation that you will now learn git, GitHub, branches, pull requests, and commit hashes is not reasonable. Those abstractions were designed for engineers. They leak in ways that experienced engineers barely notice. A rebase gone wrong, a three-way merge conflict, a detached HEAD. Most domain experts building AI skills are not engineers and should not have to become them.
The gap is real. We need version control that reads like Google Docs history, not git log. Review flows that read like a Notion comment thread, not a GitHub diff. Merge conflicts resolved in language, not textual hunks. A layer that makes collaborative skill development accessible to the people who actually have the domain expertise to build skills well.
Some of this is starting to emerge at the edges. Notion's version history. Claude's artifact versioning. Hashnode-style lightweight review. None of it is purpose-built for AI skills yet. It is an open space, and the teams that figure it out will have a meaningful advantage over teams still treating skill development as an engineer-only practice.
Is APM perfect? No.
The agent tooling ecosystem is young and moving fast. There is no universal standard for how skills, hooks, and MCP servers should be packaged. Different agent platforms expect different formats. Dependency resolution across agent configurations is a genuinely hard problem the industry has not converged on yet.
APM is the current best bet, not the final answer. It is an opinionated take on what a package manager for agent configurations could look like. The format will evolve. The registry will grow. Some of the abstractions will turn out to be wrong.
But the core bet holds: agent configurations deserve the same dependency management, versioning, and shareability that application code has had for decades.
Why portability matters
One universal way to store skills, agents, tools, and MCP servers, deployed to the agent of your choice, decouples a team's accumulated knowledge from any single vendor. A carefully tuned setup is not locked into Claude Code, Copilot, or Cursor. It is portable.
Every dependency in awesome-apm-stacks comes from repos with meaningful community adoption: obra/superpowers, anthropics/skills, github/awesome-copilot, and more. I am not building custom implementations. I am curating and composing what the community has already proven works.
If you want to try it, start with the universal foundation and compose from there:
apm install -g thinkjones/awesome-apm-stacks/user-coreWhat I'd like to hear
I do not think APM is the end state. It is a good first attempt, and Microsoft taking it into their OSS org suggests the broader industry agrees something like this is needed. But there will be other attempts, and probably better ones, and there are corners of the problem APM does not touch yet.
A few things I am actively trying to understand:
- How are other teams managing AI skills at company scale? What does the workflow look like for a team of twenty? Two hundred?
- What tooling is emerging for non-engineer contributors? Anyone building Google-Docs-style versioning for skills?
- For companies already using Notion, Confluence, or SharePoint as the source of truth for knowledge, how are you bridging that into the packaging layer?
- What have you tried that did not work, and why?
The landing page is here: Awesome APM Stacks. Issues, PRs, and stories from the field all welcome. Find me on LinkedIn or GitHub if you are working on this space.