superpowers-marketplace: a curated index of Claude Code plugins and their install commands

What the repository actually contains

The Superpowers Marketplace is a curated Claude Code plugin marketplace for skills, workflows and productivity tools. That description is accurate but understated, because the repository itself contains almost nothing.

The Marketplace Structure section of the README gives the whole thing:

superpowers-marketplace/
├── .claude-plugin/
│   └── marketplace.json       # Plugin catalog
└── README.md                  # This file

Two files, one of which is a JSON catalog and the other the readme you are reading. The top level itself holds a little more than that diagram:.claude-plugin/,.claude/, LICENSE and README.md. There is no source code, no build, no test suite and no package manifest, and the primary language in the repository metadata is not recorded.

That is worth pausing on, because it determines what this repository is for. It is a registry entry. When you add it to Claude Code with a marketplace command, the client fetches the marketplace.json, reads the list of plugins and their metadata, and then each plugin is installed from its own repository. This repository is the index; the software lives elsewhere.

The consequence is that evaluating this repository means evaluating four separate projects plus this catalog, and the licence situation is layered. The Licence section says the marketplace metadata is under the MIT License, while individual plugins are under their respective plugin licences. So the catalogue is permissively licensed, while each plugin carries its own terms that a user has to check separately.

The.claude/ directory in the top level is the other thing worth noting, since it is not described in the README's structure section. It suggests the project has some Claude Code configuration of its own, alongside the.claude-plugin/ directory that holds the catalogue itself.

The repository is not archived, the last push was on 2026-10-10, and there are no GitHub releases, which is consistent with a repository whose content is a JSON file rather than a distributed artefact.

Installing the marketplace, and then the plugins

The installation is a single command run inside Claude Code:

/plugin marketplace add obra/superpowers-marketplace

That is the whole of the marketplace installation. The slash command form matters, because it is not a shell command you run in a terminal, it is a command the agent's own command interface interprets. That is a meaningful difference from a package manager, and it is why the plugin installs below use the same shape.

Each plugin is then installed with the same pattern, taking the plugin name and the marketplace name:

/plugin install superpowers@superpowers-marketplace

/plugin install elements-of-style@superpowers-marketplace

/plugin install superpowers-developing-for-claude-code@superpowers-marketplace

/plugin install private-journal-mcp@superpowers-marketplace

The identifier before the at sign is the plugin's own name and the one after is the marketplace it comes from, which is what lets the same plugin be available from two different marketplaces and lets a user track where each came from.

None of these commands touch a shell, and none of them are npm installs. There is no package manager involved, no lockfile and no dependency resolution in the Node sense. The plugin's own repository is pulled in as a unit, and whatever the plugin needs, it brings with it.

The README also points at where problems go. Issues for the marketplace are at the superpowers-marketplace issues tracker, and there is a separate link for the core plugin, which is at obra/superpowers. That separation is the right one, since the marketplace is a catalogue and the plugins are the software, and a bug in a skill belongs in the skill's own tracker rather than in the index.

The four plugins and what each one actually adds

The catalogue has four entries, and each is described with the same five fields, which makes them comparable.

Superpowers is the core, a skills library with TDD, debugging, collaboration patterns and proven techniques, categorised under Testing, Debugging, Collaboration and Meta. What you get is 20+ battle-tested skills, the /brainstorm, /write-plan and /execute-plan commands, a skills-search tool for discovery, and SessionStart context injection. Its repository is obra/superpowers.

The SessionStart context injection is the most interesting item on that list for anyone who has used a coding agent, because it means content is injected into the session at the start rather than only being available on demand. That is a meaningful difference in how a skill behaves, since a skill you have to explicitly ask for is a skill you might forget to ask for.

Elements of Style is writing guidance based on William Strunk Jr.'s The Elements of Style from 1918, categorised under Writing, Documentation and Reference. What you get is a writing-clearly-and-concisely skill, the complete 1918 reference text at around 12k tokens, all 18 rules for clear, concise writing, and grammar, punctuation and composition guidance. The repository is obra/the-elements-of-style.

That token count is worth noting. Twelve thousand tokens of reference material in the context window is a real cost, and it is the kind of thing that only works if the model is selective about it. A skill that loads the whole book on every request is different from a skill that loads the relevant rules, and the difference is invisible until you look at what the plugin does with it.

Superpowers Developing for Claude Code is skills and resources for developing Claude Code plugins, skills, MCP servers and extensions, categorised under Development, Documentation, Claude Code and Plugin Development. What you get is a working-with-claude-code skill with 42+ official documentation files, a developing-claude-code-plugins skill for streamlined development workflows, a self-update mechanism for documentation, and a complete reference for plugin development, skills, MCP servers and extensions.

Private Journal MCP is a private journaling MCP server with semantic search, categorised under Journaling, Memory and MCP. What you get is multi-section private journaling covering feelings, project notes, technical insights, user context and world knowledge, local AI semantic search via embeddings, read recent entries with full content retrieval, and dual storage, project-local and user-global journals. Its repository is obra/private-journal-mcp.

The dual storage there is a design decision with a privacy dimension. A project-local journal and a user-global journal are two different scopes of memory, and the fact that the semantic search runs locally via embeddings rather than through a hosted API means the entries are searched on your own machine.

Skills, commands and an MCP server are three different things

The four entries in the catalogue are not four instances of the same kind of artefact, and the flat list format hides more than it shows.

The first three are skills and command sets. Superpowers is a skills library with slash commands, Elements of Style is a single skill plus a reference document, and Superpowers Developing for Claude Code is a pair of skills plus a documentation bundle with a self-update mechanism. All three work by changing what the model is told and how it is instructed. They add no new capability and no new process. They run inside the agent, they are text, and removing one leaves the agent working exactly as before.

Private Journal MCP is different in kind. It is an MCP server, which means it is a running process with a local database and a semantic search index built on embeddings. The README lists what it provides: multi-section journaling split into feelings, project notes, technical insights, user context and world knowledge, local AI semantic search via embeddings, reading recent entries with full content retrieval, and dual storage with a project-local and a user-global journal.

Two things follow from that difference. The first is a persistence question. A skill is scoped to the session or the project directory, and it is gone when you uninstall it. An MCP server with a journal and an embedding index holds data on disk that outlives any session, and the dual storage design means some of that data is deliberately long lived and personal, with sections named for feelings and for user context rather than for code.

The second is a boundary question. A skill cannot do anything the agent could not already do with the right prompt. An MCP server can, because it is reachable as a tool and it holds state the model cannot otherwise see. Installing one is a decision about what your agent can reach, not about how well it writes.

That distinction is also why the local semantic search detail matters. The README says the search is local AI semantic search via embeddings, and the search is over journal entries the user wrote. If that search ran through a hosted API, the contents of a personal journal would leave the machine on every query. The wording suggests it does not, and the phrase read recent entries with full content retrieval suggests the retrieval is a local read rather than a model call, but the project does not spell out the mechanism in the marketplace catalogue, so the plugin's own repository is where that detail is.

For a reader deciding what to install, the useful question is not which plugin is best but which kind you are adding. Skills are cheap and reversible. An MCP server with a persistent local database is a different commitment, and the marketplace lists them in the same table.

What a catalogue can and cannot tell you, and where to look instead

The value of a marketplace index is convenience, and the limitation is that an index carries only what the curator wrote down.

What the README gives you is a description, a category set, an install command, a feature list and a repository link for each plugin. That is enough to decide whether to install something, and it is the right level of detail for a catalogue, because the catalogue is not where the detail lives.

What it does not give you is the thing you would actually want before adding software to your agent. There is no version constraint listed, so you cannot tell from the marketplace whether a plugin pins a version or tracks the latest. There is no indication of how actively each plugin is maintained, and the last push date on a marketplace tells you about the catalogue rather than about the plugin. And the licence for each plugin is deferred entirely, with a single line saying to see the respective plugin licences.

That last point is the one to be deliberate about. The marketplace metadata is MIT, but a plugin that ships a third party document, as Elements of Style does with the 1918 text, brings that document's terms with it. The README does not summarise any of them, and the instruction is simply to look at the plugin's own repository.

There is also a distinction the README makes between the two kinds of entry worth noticing. The first three are skills and command sets, which is prompt and instruction material, and the fourth is an MCP server, which is a running process with local storage and a semantic search index. The former changes how the model behaves, the latter changes what the model can reach. They are grouped together in a single flat list, and the category labels are the only hint that they are not the same kind of thing.

The support section points at two places, the issues tracker for the marketplace and the repository for the core plugin, and neither is a general support channel. So the expectation is that a problem with a plugin is filed in that plugin's repository, and the marketplace is where you go when the catalogue itself is wrong, which is a rare category of problem, since a catalogue of four entries is not much that can go wrong in it.

The practical reading is that this repository is a well-organised front door to four small projects, and the one thing worth doing before installing is opening each plugin's own repository and reading its licence and its own documentation, because that is where the answers are.

Editorial conclusion

superpowers-marketplace fits a Claude Code user who wants the marketplace entry point rather than installing plugins one repository at a time, and who wants to read what each plugin contains before adding it to their agent. It is the wrong dependency if you want the plugins themselves, because this repository contains none of them, only pointers, and every plugin has its own licence that the marketplace metadata does not replace. Before installing anything, open the plugin's own repository and read its licence, and check the issues tracker if a plugin misbehaves, since the marketplace repository is not where plugin bugs are reported.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. obra/superpowers-marketplace on GitHub
4. README