Developers who run Claude Code as a "dev team" instead of a single assistant install the same short list of skills: a planning gate, a subagent-driven build loop, a code-review pass, a debugger, and frontend plus MCP-building specialists. The pattern is one orchestration skill fanning work out to focused subagents, and the install counts show which of those subagents people keep.
That "132 agents, 159 commands, 25 MCPs" screenshot going around is the flashy version of this. Under the hood it is mostly a handful of skills doing the heavy lifting, plus OpenAI shipping a plugin that runs Codex inside Claude Code, so the two agents can review each other's work. Here is the stack, ranked by how many developers actually installed each piece.
What a Claude Code dev team actually is
A single agent holds one thread and loses the plot on anything longer than a few files. The dev-team setup splits the work: one orchestrator reads intent and delegates, subagents each own a slice (build this, review that, debug the other thing), and the results come back to the main thread. You are not running 132 personalities. You are running a few reliable roles, over and over.
The skills below are the roles. Numbers come from the Skillselion catalog, ranked by real installs.
The stack, ranked by installs
1. frontend-design (anthropics/skills) - 628,875 installs
The most-installed skill in this whole space, and for good reason: it is the teammate you hand UI work to. It carries taste and layout conventions so the agent stops shipping generic scaffolding. If your dev team ships anything a human looks at, this is the front-end seat.
2. brainstorming (obra/superpowers) - 261,134 installs
The planning gate. It refuses to let the agent write code until the design is approved, one question at a time. This is the skill that turns "sounds reasonable" into an actual spec, and it is why Superpowers-style setups feel less chaotic than raw prompting.
3. systematic-debugging (obra/superpowers) - 173,346 installs
Reproduce, minimise, hypothesise, fix, regression-test. It is the on-call teammate you route a failing test to instead of asking the main thread to guess. Pairs naturally with the review step below.
4. using-superpowers (obra/superpowers) - 171,091 installs
The orchestration meta-skill. It is the layer that knows which other skill to reach for, so the main agent behaves like a lead handing tasks out rather than doing everything itself. This is the closest single install to the "turn one bot into a team" idea.
5. requesting-code-review (obra/superpowers) - 155,120 installs
The reviewer seat. It runs a review pass as a separate step with its own standards, which is exactly the slot OpenAI's Codex-in-Claude-Code plugin slides into: let Codex read the diff Claude just wrote. Two models, one review loop.
6. subagent-driven-development (obra/superpowers) - 135,061 installs
The build loop itself, the one that spawns focused subagents per task. This is the literal "dev team" pattern, and 135k installs say a lot of people are running it rather than talking about it.
7. mcp-builder (anthropics/skills) - 85,298 installs
The MCP question people ask most: not "which MCP do I install" but "how do I build one for my own stack." This is that teammate. It writes the server so the rest of your team gets a new tool to call.
8. workflow-orchestration-patterns (wshobson/agents) - 8,946 installs
Lower count, but pointed: the patterns layer for wiring multi-step agent workflows, from the wshobson/agents pack that a lot of these setups pull from. Worth it once your team has more than three roles talking to each other.
Where the Codex plugin fits
OpenAI's codex-plugin-cc runs Codex as an agent inside Claude Code. In a dev-team setup it is not a replacement, it is another seat: Claude plans and builds, Codex reviews or takes the rescue pass, and the code-review skill above is the natural handoff point. If you already run requesting-code-review, wiring Codex in is a small step, not a rebuild.
How to read these numbers
Install count is a rough vote. It does not mean a skill is best for your repo, it means a lot of developers kept it. Treat the top of this list as a worth-installing shortlist and try the ones that map to roles you actually need. A two-person "team" (build plus review) covers most days.
I run Skillselion, the directory these counts come from: live catalog, refreshed daily from skills.sh, GitHub and MCP registries, ranked by real installs. If you want the full ranked list for a specific role, browse the skills catalog. Independent project, not affiliated with Anthropic, OpenAI or Cursor.
Top comments (12)
The installed stack matters less than the coordination rules around it. Skills and MCPs help only when the agent knows when to read them, when to ignore them, and how to preserve evidence.
Agreed, and the failure mode when the coordination layer is missing is very specific: two skills with overlapping trigger descriptions, and the agent quietly stops delegating to one of them. No error, no log line, the skill just stops firing. The stack list is the easy half.
On preserving evidence, the strongest version I have found is structural rather than behavioral: run verification in a context that did not produce the code. An agent grading its own homework converges on confident wrong answers no matter what the rules file says.
That overlapping-trigger failure is exactly why I think skill registries need some kind of conflict audit, not just install success. The scary case is quiet non-use: the agent still looks capable, but one procedure has effectively shadowed another. I would rather surface that as a routing warning than discover it from behavior drift later.
Agreed, and I would split the audit into a static half and a runtime half, because they catch different things. The static half is cheap at install time: compare the new skill's trigger description against what is already installed and warn on high overlap, before anything is shadowed. But true shadowing only shows up at runtime - which procedure actually got routed. The signal that catches your quiet non-use case directly is a per-skill fire count over the last N sessions: a skill sitting at zero fires whose trigger overlaps a busy neighbor is almost certainly shadowed, no behavior-drift forensics needed. That log is nearly free to keep and it turns "the agent still looks capable" from a feeling into a checkable table.
The static/runtime split is exactly the missing layer. A registry can say two skills both match, but it cannot prove which one actually fired during the run. I like the idea of measuring shadowed skills and per-skill fire count, because quiet non-use is usually more dangerous than an obvious routing error.
The good news is the runtime half needs no registry cooperation at all: local session transcripts usually carry enough signal (tool-use entries, skill loads) to approximate per-skill fire counts, so a session-end hook can maintain them and diff against the installed set. The format is not a stable public contract, so treat it as a heuristic you re-validate per version, but the data already sits on your own disk. Zero fires over N sessions in workflows where the trigger description should have matched is exactly your "quiet non-use" signature. The piece a registry could add on top is the prior, not the proof: aggregate anonymized fire-rate-per-install across users, so you can see that a skill fires for almost nobody before you install it. Shadowing would show up there as a population-level pattern (fire rates collapse for one skill whenever a specific other skill is co-installed), which no single machine can observe locally.
That makes sense. The local transcript signal is probably enough for a first useful version, even if it has to be treated as heuristic rather than contract. The registry-level prior is the interesting second layer: it would tell you whether the skill is unpopular because your workflow is different, or because almost nobody can get it to fire in practice.
Right, and the two failure populations would look different in the data: a skill nobody can trigger shows near-zero fires across many installs, while a workflow mismatch shows healthy fires for some users and zero for you. Even before any transcript data exists you can spot likely members of the first group by reading descriptions against what else is installed; two skills claiming the same prompts will split or starve each other, and the starved one's local fire count says nothing about whether anyone actually wanted it.
That is a useful distinction. Local fire count is evidence about your environment, not necessarily evidence about demand. I like the idea of checking overlap too: if two skills are both trying to own the same trigger language, the weaker one may look unwanted when the real issue is routing collision.
No registry collects fire-rate telemetry today, so the honest second layer is a proxy: the shape of install growth over time. A skill that keeps compounding weeks after its launch spike is firing for somebody, because nothing sustains word-of-mouth installs like a skill that actually activates. A spike that goes flat the week after launch is at least consistent with shelf-ware. Those two shapes are unmistakably distinct in public install data, even though the curve cannot tell you which individual install went dead.
One bias to design around before trusting any registry-level prior: fire rates cluster by stack. A frontend skill fires constantly for frontend developers and never for a data engineer, so a global prior would mark it broken for half its audience. The prior needs conditioning on workflow, which is exactly the thing your local transcript signal gets for free.
That is the honest layer. Local fire-rate telemetry tells you what your environment actually uses, but provenance tells you whether that usage should be trusted. Without both, teams either install blindly or delete useful skills because they look quiet.
Install shape is a decent proxy because sustained installs imply repeated activation somewhere. I would still separate curiosity installs from retention: a skill that gets added, kept, and referenced again is a much stronger signal than a launch spike with no later use.