Designing a Coding Agent Skills Marketplace for Your Organisation

Dominik Bermühler · May 7, 2026 · 10 min read

Coding AgentsAI

At AutoScout24, coding agents are part of how we work. As code becomes a commodity, engineers increasingly operate as architects who orchestrate agents rather than writing every line themselves. With dozens of teams working across tech stacks and time zones, shared knowledge becomes essential. Repeatable workflows, org-specific conventions, integration patterns: these things would otherwise live in someone’s head or a Confluence page nobody reads.

We needed a way to package and distribute these agent capabilities across the organisation: a skills marketplace. The core idea is tool-agnostic: a governed registry of reusable agent skills, contributed by any team and installable by any engineer, regardless of which coding agent they use.

This post covers how we designed our internal skills marketplace: the technical structure, the governance model, and the automated quality gates that hold it all together.

#What is a Skills Marketplace?

A skills marketplace is a Git repository that serves as a governed registry of reusable agent capabilities. In our case, the repository uses the Claude Code plugin marketplace format: each plugin bundles skills, sub-agents, slash commands, hooks, MCP/LSP server connections, and output styles. The marketplace collects these plugins in one place so engineers can discover, install, and update them regardless of which coding agent they use.

For Claude Code users, interaction happens through built-in plugin management:

# Add the marketplace
claude plugin marketplace add AutoScout24/agent-skills-marketplace

# Browse available plugins
claude plugin marketplace list

# Install a plugin
claude plugin install jira

Codex users install the same skills via the skills CLI:

# Install a skill
npx skills add https://github.com/AutoScout24/agent-skills-marketplace/tree/master/plugins/jira

Once installed, a plugin’s components become available to the agent automatically. The key benefit is composability: teams install only what they need for a given project.

#Why You Want One in Your Organisation

Without a shared marketplace, knowledge stays siloed. One team writes a great prompt for interacting with Jira, another team writes a slightly different one, and a third team never discovers either. Multiply that by every common workflow (PR reviews, security checks, deployment patterns, onboarding) and you get a lot of duplicated effort and inconsistent quality.

A marketplace solves this by providing a single, discoverable place for shared agent capabilities. There are three reasons a marketplace pays off at organisational scale:

Maintainability. When a skill changes (Jira fields get renamed, a deployment process evolves), there is one place to update it and every user benefits. Without a marketplace, the same fix needs to happen in every team’s local copy, if they even notice it broke.

Standardisation without rigidity. A marketplace lets you encode org-wide workflows (how to generate API documentation, how to run security code reviews, etc.) into skills, agents, and hooks, then bundle them into composable plugins. Teams pick the plugins that apply to their project and skip the rest.

Multi-agent compatibility. The skill format (SKILL.md with YAML frontmatter) is supported by both Claude Code and Codex. Engineers write a skill once and it works regardless of which agent consumes it.

#Designing the Technical Structure

#How a Marketplace Repository is Structured

The repository follows the Claude Code plugin marketplace convention. This was a deliberate choice: it provides a well-defined format with built-in discovery and installation tooling, while keeping the core skill format (Markdown + YAML frontmatter) portable to other agents. The structure looks like this:

├── .claude-plugin/
│   └── marketplace.json              # Central registry: name + source path only
│
└── plugins/
    └── <plugin-name>/
        ├── .claude-plugin/plugin.json   # Plugin metadata (name, description, version)
        ├── skills/<name>/SKILL.md       # Reusable skills
        ├── agents/*.md                  # Sub-agents
        ├── commands/*.md                # Slash commands
        ├── hooks/hooks.json             # Event handlers
        ├── styles/*.md                  # Output formatting
        ├── .mcp.json                    # MCP server connections
        └── .lsp.json                    # LSP server configs

The marketplace.json at the root is the entry point. It tells the agent tooling which plugins exist and where to find them. It contains only the minimal pointer information: plugin name and source path. Each plugin then lives in its own directory with a plugin.json manifest that holds all its metadata (name, description, version) and whatever combination of components it needs. Not every plugin needs all component types; most start with just a skill or two.

The key structural choice is that each plugin is self-contained. A plugin directory holds everything it needs: its metadata, its skills, its hooks, etc. This makes plugins independently installable, independently versionable, and independently ownable. It also means teams can update their plugin’s version and description without touching the central registry file. Only adding a new plugin to the marketplace requires a change to marketplace.json. This distinction is the foundation of the governance model.

#Governance: Collaboration with Guardrails

The marketplace is open to contributions from any team in the organisation. That openness is intentional: the best skills come from the teams closest to the problem. But openness without governance leads to inconsistency, abandoned plugins, and quality drift.

#Clear Ownership via CODEOWNERS

Every plugin directory has a designated team owner in GitHub’s CODEOWNERS file:

# Default owner for everything
* @acme/platform-engineering

# Per-plugin ownership
/plugins/jira/        @acme/platform-engineering
/plugins/onboarding/  @acme/developer-advocacy
/plugins/auth-lib/    @acme/identity-team
/plugins/cdk/         @acme/cloud-infrastructure

Ownership means responsibility: the owning team reviews PRs, maintains the plugin over time, and fixes issues. But ownership does not mean exclusivity. Any team can open a PR against any plugin. If someone finds a bug in the Jira plugin or wants to improve the onboarding skill, they submit a PR and the owning team reviews it. This creates a open source dynamic where plugins improve through contributions from across the organisation, not just from the team that originally built them.

#Platform Engineering as Gatekeeper for New Plugins

The platform engineering team owns the repository itself. While teams own individual plugins, platform engineering has final say on whether a new plugin gets added to the marketplace. This ensures every plugin in the marketplace serves the broader organisation, follows the design guidelines, and meets quality standards.

The result is a two-tier model: autonomy for updates, governance for additions. A team updating their own plugin experiences minimal friction. A team proposing a new plugin gets platform engineering review to ensure it fits the marketplace’s scope.

#What Belongs (and What Does Not)

We are explicit about scope. The marketplace is for plugins that solve common, shared problems across the organisation. Good fits include plugins that encode org-wide standards, provide tooling applicable across tech stacks, or solve problems many teams share.

Plugins specific to one team’s internal workflow, tailored to a single project, or encoding team-specific conventions do not belong. For those, we encourage teams to create their own marketplace repository. Regardless if a developer prefers Claude Code or Codex, the tooling supports multiple marketplaces, so teams can maintain their own alongside the shared one.

#Automated Quality Gates: The Linter

Governance through code review alone does not scale. Reviewers miss structural issues. Contributors forget steps. And expecting a central team to manually verify plugin structure on every PR creates a bottleneck.

The idea to invest in a custom linter came from OpenAI’s harness engineering post about building agent-first applications. They describe how custom linters that enforce structural rules mechanically become multipliers in agent workflows. Once encoded, they apply everywhere at once. The same applies here: plugins in our marketplace are often created and modified by coding agents themselves. In that context, structural checks that might feel pedantic to a human become essential. They are a consistent enforcement layer that catches what neither the contributing agent nor the reviewing human would reliably notice.

Our solution is a custom linter that runs as a required CI check on every pull request. It validates plugin structure, registry consistency, skill conventions, CODEOWNERS entries, and version bumps on every change. The PR cannot be merged unless the linter passes, regardless of who approved it.

#Why Automation Matters Here

The linter replaces what would otherwise be platform engineering’s manual quality review for structural issues. Contributors get fast feedback (run the linter locally before pushing), the CI catches anything missed, and platform engineering does not need to be in the review loop for every routine change.

This is the key that makes distributed ownership work at scale. Without automated gates, you either bottleneck through a central team or you accept quality drift. The linter gives you neither: teams move fast, and standards are enforced consistently.

#The Contribution Process

We invested in making the contribution process explicit and repeatable. Our CONTRIBUTING.md covers everything from “is my idea a good fit?” to “how do I test locally?” to “what happens during review?“.

The steps are:

1. Validate scope (reach out to platform engineering for early feedback)
2. Create the plugin directory with the required structure
3. Add the plugin to marketplace.json
4. Add your team to CODEOWNERS
5. Open a PR

Contributors can test locally without installing. In Claude Code, use claude --plugin-dir ./path/to/plugin to load the plugin for a single session without modifying any config. In Codex, point the skills CLI at a local clone.

The versioning policy uses semantic versioning: patch for bug fixes, minor for new features, major for breaking changes. This gives users visibility into the nature of updates.

#Lessons from Building This

Start with exploration, then standardise. Our marketplace grew out of individual engineers sharing skills informally. The need surfaced organically through our live coding sessions, where engineers wanted better ways to share workflow improvements across teams. The marketplace repository itself was created grassroots-style by software engineers. When it became clear that the concept needed professionalisation (governance, quality gates, scalable contribution processes), security and platform engineering stepped in together to define and build the structure that now serves the whole organisation. If we had designed the marketplace before anyone was writing skills, we would have over-engineered in the wrong directions.

Automate the boring gatekeeping. Every check the linter performs is something a human reviewer would otherwise need to verify manually. Humans are bad at checking whether a name is kebab-case or whether a source path is correctly formatted. Machines are great at it.

Make the right thing easy. The plugin directory structure, the manifest fields, the contribution steps: all are documented with examples. When the path of least resistance leads to a well-structured plugin, you get well-structured plugins.

Design for multiple agents from day one. Supporting Claude Code and Codex from the start meant we never had to retrofit compatibility. The shared skill format works across agents, and the plugin structure allows each agent to leverage whichever components it supports.

#Where This Is Going

The marketplace today has 16 plugins contributed by multiple teams. It covers workflows from Jira issue management to security reviews, from frontend standards to database operations. But the structure is designed to grow without the governance model breaking down.

As coding agents become more capable, the components in these plugins will evolve too. Skills that today are prompts may tomorrow orchestrate multi-step workflows through agents and hooks. New agents that understand the skill format can tap into the same marketplace without any migration effort. The plugin format already supports this progression. The marketplace provides the collaborative environment to get there together.