It didn't take long until skills became a key element in our agentic development workflow. At that moment a skill stopped being "that SKILL.md I keep in one project" and became something we want on every machine, for every teammate, without copy-pasting a folder around. That's the point where you package it into a plugin. A plugin is a container: it bundles one or more skills plus optionally commands, agents, hooks, and MCP servers into a single installable unit with a manifest. Skills are the "what to do", plugins are the "how you get it onto someone else's machine". Our first approach: using git submodules Our first approach was through centralizing all our skills in a separate Git repo and share it between projects by using git submodules. That approach worked but felt more like a hack than a final solution. The better approach: wrap it in a plugin A plugin is just a directory with a manifest and a conventional layout: my-plugin/...
Yesterday I was talking about git submodule support in Visual Studio and that reminded me of something else: Azure DevOps Server got submodule support too. It's a small feature, but a genuinely useful one. Why do we need this? If you've worked with submodules before, you know the annoying part isn't adding them, it's navigating them afterwards. In the Files hub, a submodule used to just show up as a folder reference. To actually browse its content, you had to know the submodule's repo, open it separately, and find the right commit yourself. What changed Azure DevOps Server now has UI support for Git submodules in the Files hub. You can click straight into a submodule from your project and land exactly on the commit that's referenced there. No more manually tracking down the right repo and commit by hand. It works across multiple Git services that a submodule can point to: Azure Repos GitHub GitLab Bitbucket Multiple .gitmodules URL...