When you work with AI assistants like Claude Code, there comes a moment when your skills stop being a personal trick and become a tool your team needs. At first, you solve it like any developer: zip the folder, send it over Slack or share it in a repo. But soon you realize that ZIP is a problem disguised as a solution. No versions, no traceability, and every manual copy turns into a silent fork that nobody knows how to update. At Q2BSTUDIO, where we develop custom software applications for companies that need precision and scalability, we know that managing technical knowledge cannot rely on loose files. The answer is not another shared repository but a plugin marketplace with identity, versions, and a central catalog. In this article I explain how to create yours in fifteen minutes using agkit, a tool that removes the friction of maintaining a professional skill ecosystem.
The root problem is not technical; it is conceptual. When you have a skill that converts your staged diff into a conventional commit, and you use it a dozen times a day, sharing it feels natural. But by doing so, you introduce an update vector. Each person who receives it works on a copy, with no link to the origin and no way to know if they have the latest version. A shared repo with fourteen mixed skills is like a junk drawer: you can clone it, but then you have to hand-pick what you need, and at that very moment you have created a fork. If another team publishes an excellent skill, you are forced to copy it or ask your team to clone a second repository. The solution comes from two elements that the industry already understands: the plugin as a unit and the marketplace as a catalog.
A plugin is not just a folder with files; it is a unit with identity. It has a name, version, author, and description. It installs, updates, and uninstalls as a whole. Claude Code and GitHub Copilot already model extensions this way. What is missing is the infrastructure to create and maintain that model effortlessly. And that is where agkit comes in, a tool that does not reinvent anything but makes the obvious cheap to implement. Think of it as Angular's ng for agent-plugin marketplaces: one command creates a push-ready repository, and a few more cover the full lifecycle. At Q2BSTUDIO, when we tackle artificial intelligence or automation projects, we apply exactly this principle: the simplicity of the tool should not hide the complexity of the domain, but level it.
The process starts with a scaffold. With Node.js 22 or higher, run npx agkit init dev-toolkit and answer a few basic questions: name, owner, description, and git remote. In seconds you get a directory with a catalog at .claude-plugin/marketplace.json, an empty plugins/ folder, a README with a pre-filled installation section, an AGENTS.md for agent context, and even a CI workflow. The catalog is a plain JSON with a schema, enabling editor autocomplete and validation from the first commit. No build, no compilation: the agent reads it as is. This means you can serve Claude Code, Copilot, Codex, and Cursor from the same repository, because they all understand that format natively. At Q2BSTUDIO, when we integrate AWS or Azure cloud services, we particularly value that one infrastructure can serve multiple environments without duplicating effort. Exactly the same happens here: one catalog, four agents.
Once you have the skeleton, add your first skill with agkit add skill commit-crafter. The tool offers several built-in templates: skill, command, agent, hook, and MCP. The template generates two files (a SKILL.md and a manifest) and registers the plugin in the catalog. The SKILL.md comes with placeholder instructions; the important part is that the description in the front matter is what Claude reads to decide whether to load the skill, so it is worth writing it carefully. You replace the skeleton with the real content of your skill: the logic to detect staged changes, choose the commit type, and generate the message. The manifest plugin.json is the source of truth; if you later edit it manually, just run agkit sync and the catalog, README, and AGENTS.md all catch up automatically. This prevents information drift, a common issue in Business Intelligence and Power BI projects where multiple dashboards depend on the same data source.
Here comes the point that really differentiates a marketplace from a junk drawer: you can reference plugins that live in other repositories without copying a single line. With agkit add octo-org/changelog-skill changelog --ref v1.2.0, your catalog gains an entry pointing to that external repository with a pinned tag. Your team does not download that plugin's code; they fetch it directly from the original source at install time. You do not have to maintain a copy, you do not have to track updates. If you want to move the reference to a later version, use agkit add ... --ref v1.3.0. If you need to take ownership of the code and modify it, use the --vendor flag to clone it into your plugins/ folder. The rule is simple: reference by default, clone only when you want to own. At Q2BSTUDIO, we apply the same philosophy when working with third-party libraries in cybersecurity projects: we integrate what is proven without creating an unnecessary fork, but we reserve the right to fork when code control is critical.
Before publishing, you validate with agkit validate. The tool checks JSON validity, kebab-case names, reserved names, source resolution, manifest presence, and version consistency. If you have the Claude Code CLI installed, it also runs the agent's native validation. The CI workflow generated at init already includes this command, so any pull request with a broken catalog will be rejected. Publishing is simply git push. No central registry, no publish token. Your team can add your marketplace with /plugin marketplace add jane/dev-toolkit and install any plugin with /plugin install commit-crafter@dev-toolkit. If you also copy the generated examples/team-settings.json into Claude's configuration directory, the marketplace is added automatically when team members trust the repository. That means zero manual steps for developers. This reminds me of how Q2BSTUDIO facilitates the adoption of process automation: the orchestration must be invisible to the end user.
The real paradigm shift comes with versioning. A skill is not a static folder; it is a product that evolves. You improve your commit-crafter to detect breaking changes, commit with a conventional message (feat(commit-crafter): detect breaking changes and add a BREAKING CHANGE footer), and then run agkit bump commit-crafter --tag. The tool analyzes commits touching that directory since the last tag, applies conventional commit rules (feat = minor, fix = patch, feat! = major), writes the changelog, updates the version in the manifest and catalog, syncs README and AGENTS.md, and commits with the corresponding tag. All in one command. You do not have to touch any version or changelog manually. And because each plugin has its own tag (commit-crafter@0.2.0), releases of one skill do not contaminate another. When your teammate runs /plugin update, they get exactly that version. This is what it means to treat skills as software that is distributed, not files that are shared. At Q2BSTUDIO, when we develop custom applications, we apply the same semantic rigor: each module has its own lifecycle and independent versioning.
There is one detail you should not overlook: you cannot bump a referenced remote plugin (like the changelog in the example). Its version is controlled by the original author. To move it forward, you re-pin with agkit add ... --ref new-version. This is correct, because it prevents your catalog from becoming an upstream version manager. You are the curator, not the maintainer. And if one day you decide you want to modify that plugin, you add it with --vendor and from that moment it is yours, with everything that entails. This distinction between reference and copy is the same we apply in hybrid cloud projects: you know which services you consume as SaaS and which you manage yourself. Clarity of boundaries avoids headaches.
To close the loop, think about the full ecosystem. Such a marketplace can serve Claude Code, Copilot, Codex, and Cursor from a single repository, without duplicating plugin content. The key is that the catalog is the only source artifact; everything else (README, AGENTS.md, registries for Codex and Cursor) is derived from it via agkit build or agkit sync. This ensures no drift: what you see in the catalog is what gets installed. And if your team uses different forges (GitLab, Bitbucket, Gitea, self-hosted), agkit adapts because distribution is simply git. The tool does not impose GitHub as the only channel, something we value at Q2BSTUDIO when managing multicloud environments where each client has its own repository policy.
In the end, the mindset shift is subtle but profound. You stop seeing your skills as files to zip and send, and start seeing them as plugins you publish, version, and update. No external platform or special account needed; with a git repository and agkit you have everything. The ZIP was a quick fix that turned into technical debt. The marketplace is a fifteen-minute investment that pays dividends every time someone installs, updates, or discovers a skill. And when that someone asks, 'Can you send me that skill?', you no longer reply with an attachment, but with a terminal line: /plugin install commit-crafter@dev-toolkit. Your team will thank you, and you will stop being the informal administrator of a junk drawer to become the editor of a catalog that evolves orderly. As we always say at Q2BSTUDIO, well-structured technology not only solves problems: it removes friction so the team can focus on what really matters.
