Note: this post is part of a series. Part one covered packaging a skill in a plugin for Claude Code . Same idea, different tool, this time focussing on GitHub Copilot. After writing that first post I got the obvious follow-up question: does this also work for GitHub Copilot? Short version: yes, SKILL.md itself is portable, but the plugin wrapper isn't. Copilot CLI has its own plugin format, laid out slightly differently from Claude Code's. What's the same? A skill is still just a folder with a SKILL.md inside: YAML frontmatter ( name , description , optionally license ), then a Markdown body with instructions. Copy that file as-is between tools — nothing about the skill content needs to change. What's different? Where Claude Code wants the manifest tucked inside .claude-plugin/plugin.json , Copilot CLI puts plugin.json straight at the plugin root: api-testing-plugin/ ├── plugin.json # Required manifest, at the root ├── agents/ #...
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/...