Inside the Claude Code Plugin Marketplaces Built for Revenue Teams

Why I am paying attention to this now

Anthropic's own funding announcement this year put a number on something I have felt anecdotally for months: Claude Code's run rate revenue has grown to over 2.5 billion dollars, more than doubling since the start of 2026, and business subscriptions to Claude Code have quadrupled in the same window, according to Anthropic's Series G announcement. That is not a developer tool growing in a dev-only bubble. A meaningful share of that growth is coming from non-engineers, including people on revenue teams, who found out a coding agent can build and run their internal tools.

I build GTM systems for a living. So when a coding agent starts showing up as infrastructure for sales and marketing ops, not just for shipping product code, I go look at what people are actually building with it. Two projects stood out because they are not tutorials or predictions. They are working marketplaces you can install today.

What a Claude Code plugin marketplace actually is

A "skill" or "plugin" in Claude Code is a packaged instruction set, usually a markdown file with YAML frontmatter, that tells the agent how to do one job well: draft a cold sequence, enrich a lead list, summarize a call recording, route a request to the right CRM field. A marketplace bundles many of these together with an install mechanism so a team does not have to write its own from scratch. Instead of one agent that vaguely knows about sales, you get dozens of narrow, tested skills the agent can call on demand.

This matters for GTM specifically because most revenue workflows are not one task. They are chains: find the account, enrich it, write the sequence, load the list, monitor replies, log the outcome. A marketplace is an attempt to pre-build each link in that chain so a non-engineer on a revenue team can assemble the chain in plain language instead of writing scripts.

Inside sales-skills/sales: the router pattern

The sales-skills/sales repository on GitHub is the more sprawling of the two. It is organized as a single router skill, installed with one command, that sits in front of hundreds of specialized skills. You describe the objective in plain language and the router matches you to the right specialized skill instead of you having to memorize platform-specific commands.

What is actually inside is a genuinely wide net: prospecting and pipeline skills for lead research, ICP definition and forecasting, active-deal skills for demo prep and proposals, and integration skills for outreach platforms, email verification tools, data enrichment providers, CRMs, note-takers, help desk platforms and social listening tools. Skills can be deployed across Claude Desktop, claude.ai, ChatGPT, Gemini and Perplexity through packaged files, not just the terminal.

Inside GTM Agents: 67 plugins and cost-aware model routing

The second project, GTM Agents, is smaller and more opinionated. It is a Claude Code plugin marketplace built specifically for revenue teams, containing 67 pre-built plugins that act as slash commands covering prospecting, campaign orchestration, churn prediction and workflow orchestration, according to a repo review by Florian Narr.

The detail I found most useful is the model routing. Of the 67 plugins, 58 run on Haiku for fast, cheap execution on data processing and routine tasks, while 34 run on Sonnet for the reasoning-heavy work: strategy and creative output. (The counts overlap because some plugins call both models in sequence.) The pattern is Sonnet for strategy, Haiku for execution, Sonnet again for optimization. That is a real cost-control decision baked into the architecture, not an afterthought, and it is the same instinct I apply when I decide which parts of an outbound motion actually need a heavier model versus a cheap one running in a loop.

Why the Haiku and Sonnet split matters if you are building your own

Most teams that start automating GTM work make the same mistake I made early on: routing everything through the most capable model available because it is the path of least resistance. It works, right up until the bill for a workflow that enriches ten thousand accounts a month arrives. GTM Agents' split is a useful template. Routine, structured tasks (formatting a list, checking a field, drafting a templated follow-up) do not need your best model. Strategic tasks (positioning a sequence, deciding an ICP cut, judging whether a reply is a real buying signal) do. Designing that split into a tool from day one, rather than retrofitting it after a cost review, is the difference between a tool that scales and one that gets quietly abandoned.

Comparing the two marketplaces directly

What these marketplaces get right

Both projects prove something I tell prospective clients constantly: the bottleneck in GTM automation was never the model. It was packaging the model into something a revenue operator could actually run without learning to code. A router that maps plain language to the right skill, and a plugin set that already knows the difference between a lookup task and a strategy task, both remove real friction. I would rather hand a new hire one of these than a blank Claude Code terminal and a wiki page.

Where they still fall short

Neither is a finished product you can hand to a non-technical team with zero oversight. The GTM Agents review noted that commit activity slowed considerably after November 2025, with only two commits logged as of April 2026, a sign the project is maintained but not being actively pushed forward. Wide skill libraries like sales-skills/sales also mean uneven quality: a skill wrapping a tool you do not use, or one that has not been touched since the underlying platform's API changed, will fail quietly if you are not checking outputs. Treat both as a starting scaffold you audit and prune, not a system you trust blind on day one.

How I would actually use one of these alongside a real outbound stack

I would not replace my sending stack with a skill marketplace. I would wrap it around one. My sequencing and personalization still run through Salesforge because that is the layer that actually needs deliverability discipline, warm inboxes and send-time logic, not a general-purpose agent improvising it. Where a marketplace like GTM Agents earns its keep is upstream and around the edges: enrichment prep, drafting sequence variants for a human to approve, summarizing call notes into CRM fields, flagging accounts that match an ICP cut before they ever hit a list. Agent Frank already runs a version of this end to end for outbound specifically; a general skill marketplace is closer to a Swiss army knife for the surrounding ops work.

A practical adoption checklist for GTM teams

If your team wants to try one of these marketplaces, work through this before you install anything broadly:

1. Pick one workflow, not the whole stack. Enrichment prep or call-note summarization are low-risk starting points.
2. Install through the router or a single plugin, not the entire library, so you can audit what actually gets used.
3. Run every new skill against a throwaway list or a past deal first.
4. Check whether the marketplace routes cheap models to routine tasks. If it does not, ask why before your bill tells you.
5. Revisit in 60 days. Skill marketplaces built on fast-moving APIs go stale; check commit activity the way you would check a vendor's changelog.

Where this is heading

I expect the next twelve months to bring more of these, and better ones, as more revenue teams realize a coding agent is not just for engineers. The projects worth watching will be the ones that treat model cost as a design decision from the start, the way GTM Agents does, and the ones that stay honestly maintained rather than shipped once and left. For now, both projects I looked at are real, usable, and worth a pilot on a narrow workflow before you hand them anything that touches a live prospect.

FAQ