Marketplace

opens next month

Curated plugins and skills from across the community, gathered in one place so you can install what you want in one command. We do not write them and we do not own them — every collection stays its author's, under their name. Not live yet; this page is what it is for and how it will work, published before the thing exists rather than after.

What a marketplace is

A marketplace is a catalog someone else can add to their own tooling with a single command. They point at it once; from then on every plugin in it is installable by name, updates arrive without anyone re-sending a zip, and versions are pinned rather than vibes.

  1. add the marketplace
  2. install a plugin
  3. reload
  4. it is just there

That last step is the whole point. A skill that lives in somebody's home directory helps one person; the same skill in a catalog helps everyone who has added it, and keeps helping when it is updated.

Why packaged practice needs a channel

A skill is a folder with a SKILL.md in it: frontmatter saying when it applies, then the instructions. Its economics are unusual — only the description sits in context, and the body loads when the task calls for it. Long reference material costs almost nothing until it is used.

“A skill's body loads only when it's used, so long reference material costs almost nothing until you need it.”
Claude Code documentation, on skills ↗

That makes a skill the right container for a practice: a review checklist, a deployment recipe, a house style, a policy that caps how much an agent is allowed to spend. What has been missing is the channel. Practices get pasted into chat, screenshotted into Slack, and copied between machines until three people have three versions and nobody knows which is current.

Plugin, skill, marketplace

The three words get used interchangeably and are not the same thing.

thingwhat it islives
Skillone practice: frontmatter plus instructionsa folder with a SKILL.md
Plugina bundle of skills, agents, hooks and serversa repository with a manifest
Marketplacea catalog of plugins others can installone command, then updates
Each layer exists to solve the layer below it not travelling well on its own.

What this one does

It curates and it gathers. Good skills already exist, scattered across repositories, gists and people's home directories; what is missing is somewhere to find the ones worth having and install them without hunting. That is the whole job — selection and a single front door, not authorship.

  1. a creator publishes
  2. we select and index
  3. you install what you want
  4. updates come from them

Nothing is rewritten on the way through. A plugin listed here is the author's plugin, installed from the author's source, updated when the author updates it. Curation is a judgement about what to list — it is not a claim on the work.

The selection so far

9 candidates

Read out of the public community catalog — 2,269 plugins — and checked against the GitHub API for licence and traction. Published early because a selection is easier to argue with than a promise.

Candidates, not listings: nobody here has been approached, and nothing has been run end to end yet. Everything shown carries a licence, because that is the condition for appearing at all — one candidate was dropped for having none.

Cost and token discipline

What a session actually spends, which is the part of the bill nobody watches.

claude-cost-tracker ↗ by MayurBhavsar · MIT

Real-time token usage and cost analytics. Tracks spend per developer.

burn ↗ by into-the-intraverse · MIT · 1 stars

Shows how much money you are burning on a session.

agent-memory ↗ by Keshab0310 · MIT · 2 stars

Memory compression, with a claimed 60–90% saving on token costs.

The saving is the author’s claim; we have not measured it.

Evidence and evaluation

Whether a change made things better, answered with a number rather than a feeling.

promptfoo-evals ↗ by promptfoo · MIT · 23,596 stars

Teaches coding agents to create and maintain promptfoo eval suites.

evalview ↗ by hidai25 · Apache-2.0 · 124 stars

Behaviour regression testing — detects when an agent’s behaviour drifts.

Review across models

A second opinion from a model that did not write the code, which is the only kind worth having.

byom-review ↗ by jkrish · Apache-2.0

Code review against any model via OpenRouter, standard or adversarial.

adversarial-review ↗ by bobby-beckmann · MIT · 6 stars

Adversarial planning and review between Claude Code and OpenAI Codex CLI.

Agents talking to each other

The part that decides whether a set of plugins is a system or a pile.

agent-comm ↗ by keshrath · MIT · 4 stars

Agent-agnostic intercommunication — agents share state and coordinate.

agent-discovery ↗ by svmnikhil · MIT · 1 stars

Discover, review, install and manage agent configurations from a catalog.

Nine of ten survived the licence rule. The tenth had no licence file, which means all rights reserved rather than free — its author can add one and be listed the same day.

Not only Claude Code

A skill is a folder with a SKILL.md in it, and that format is an open standard — written by Anthropic, released rather than kept, and adopted by around forty-five products: Cursor, OpenAI Codex, GitHub Copilot, VS Code, Gemini CLI, Goose, OpenHands, Roo Code, opencode, Amp, Mistral Vibe and more. The same folder works in all of them.

whattravels to other tools?
A skill (SKILL.md and its files)yes — an open standard, adopted broadly
An MCP server inside a pluginyes — its own cross-tool standard
The plugin wrapper: hooks, agents, manifestno — that is Claude Code packaging
Which is why this is a catalog of skills that also serves plugins, rather than a plugin catalog that might one day be ported.

So entries are indexed at the level of the skill, not only the bundle it arrived in — a plugin containing four skills is four things a Cursor user might want, and today they cannot find them. And every entry says which tools it actually runs in. Of the 2,269 plugins in the public community catalog, 99 mention another tool at all. The ecosystem is portable in principle and unlabelled in practice; that label is the part worth adding.

Whose work it is

The single rule this marketplace is built around: credit goes to whoever wrote it, visibly, everywhere it appears. Aggregators have a long history of quietly becoming the brand on other people's work, and that is the failure mode being designed out rather than apologised for later.

what appearswhose name is on it
A plugin or skillits author — named on the listing, linked to the source
A collectionits creator — it stays their collection, not a section of ours
The selection itselfours — choosing what to list is the only part we did
The last row is the entire extent of our claim. Everything above it belongs to somebody else and says so.

In practice that means a creator's collection is presented as theirs rather than dissolved into a generic catalog, the listing links back to where the work actually lives, and updates follow the author's own repository rather than a copy we control.

Licensing follows from the same shape. We index and link; we do not host. Installing pulls from the author's source, so nothing is rehosted, mirrored or vendored, and no licence's redistribution terms are ever exercised on our side. Licence files, attribution and copyright headers stay exactly as written, and nothing is relicensed. Work published without a licence is not listed at all: no licence means all rights reserved rather than free, so anyone we sent there could not lawfully use what they found. Adding a licence is all it takes to be listed.

Asking in, asking out, asking back in

A creator's relationship with this catalog is theirs to set, in both directions and as many times as they like. Three requests, all of them always open:

requestwho can make itanswer
Take my work downanyone listedremoved, no argument, no negotiation
Put me backanyone previously removedwelcome back — leaving is not a ban
List me — I have never been hereanyone with work to listreviewed against the curation bar
Only the third is a judgement call. The first two are the creator's decision, not ours, and are honoured without conditions.

What is settled is the answer to each. How the request reaches us is not: a tracked channel on this site is the obvious shape, so a request has a state and a reply rather than sitting in somebody's inbox, but it is not built. Until it is, the commitment stands regardless of how you get hold of us — a creator does not have to wait for our tooling to get their own work taken down.

Not decided yet

Published in the open because a launch page that hides its open questions is a brochure. These are genuinely undecided:

  • What curation actually screens for beyond "it works", and whether that bar is published — it needs to be, now that anyone can ask to be listed against it.
  • Whether it is public from day one or starts private while the set settles.
  • How the three requests above are received and tracked — a ticket queue on this site is the likely answer, and it is not built yet.

Where this goes

Catalogs are multiplying — an official one, a community one with well over two thousand entries, and a growing number run by individual teams and vendors. Finding something means searching each of them in turn, which is the problem one more catalog would make slightly worse.

So the direction is to sit above them rather than beside them: a single index across every catalog, searchable at the level of the skill, with the author, the licence and the tools it runs in on every entry. Not a list of lists — that just hands the reader the same four tabs. And not a curated shelf alongside a bigger catalog either: one surface, where being listed means it cleared the bar and being absent means it did not.

This site already did the equivalent for models. It is not a directory of vendors; it is one table across all of them with the source on every figure. Same move, applied to skills.

Opening next month. Until then the Log carries the thinking behind it.