Ten you can actually install — how to install them · what each removes · when not to
2026-08-29 · BigCat
Install counts on these leaderboards can double in five months, so every entry here comes with a line about when it becomes a burden — that line is the part that doesn't expire.
A skill is a folder containing a SKILL.md, which an agent pulls into context only when it judges it relevant to the task at hand. Since Claude Code shipped its plugin system in October 2025, this has grown into a whole market: an official repo, several third-party marketplaces, endless "best N skills" listicles. This issue hands you ten real, installable coding skills: what each takes off your plate, the exact command, and when installing it hurts. The judgment criteria come afterwards — because lists expire and criteria don't. This is the opening issue of the series; later issues take the best of these apart one by one.
// 01
The list first: ten coding skills you can install today
Claim: the combination that actually works for coding is "one process backbone + three or four high-frequency actions + one skill for making skills." Every entry below has a repo or marketplace page; installation commands are in the second block.
INSTALL WHAT IT TAKES OFF YOUR PLATE WHEN NOT TO
------------------------------------------------------------------------------------------------------------------
superpowers The whole pipeline: plan -> TDD -> review A ten-minute fix
code-reviewer diff -> findings ranked by severity You already have strict CI + human review
git-commit-writer staged diff -> commit message Your team has no commit convention
pr-description-writer branch diff -> PR body + test plan Repos where every change is tiny
changelog-generator commit range -> semver entry Projects that never cut releases
env-doctor Local env triage: Node/venv/Docker Everyone develops in containers
truth-first Forces it to run the code before claiming done You value short answers more
webapp-testing * Opens the page and verifies your frontend change Backend-only / CLI projects
mcp-builder * Scaffolding for writing an MCP server You have no plans to write one
skill-creator * Scaffolding for writing SKILL.md -- install this one regardless
------------------------------------------------------------------------------------------------------------------
* = from Anthropic's official anthropics/skills repo; the rest are single-purpose
skills from a third-party marketplace
How to install (three routes, all commands official)
# (1) Official repo anthropics/skills (everything marked *)
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills
/plugin install document-skills@anthropic-agent-skills
# (2) Superpowers: one command via the official plugin source
/plugin install superpowers@claude-plugins-official
# Cursor: /add-plugin superpowers# Gemini CLI: gemini extensions install https://github.com/obra/superpowers# (3) Single-purpose skills from a third-party marketplace: no command,# just a folder. Download the zip -> unzip into ~/.claude/skills/<name>/# -> restart the agent and it picks it up.
Entry by entry
superpowers (obra, MIT; per its GitHub repo page, about 279.8k stars as of 2026-08): it doesn't do one thing — it nails seven stages into a mandatory pipeline (brainstorm → git worktree → write a plan → subagent-driven implementation → TDD → code review → finish the branch), across 15+ agents. The bigger the task the better it pays; on small work it is pure overhead.
code-reviewer / git-commit-writer / pr-description-writer / changelog-generator: all four are "a diff goes in, a piece of conventional prose comes out" — useful the moment you install them, with a low ceiling. Per Agensi's install-count leaderboard (page published 2026-03, updated 2026-04) they sit at 764 / 232 / 127 / 44 installs.
env-doctor: local environment triage — Node versions, Python venvs, Docker caches, the "it worked yesterday" class of problem. Useless if your whole team develops in containers.
truth-first: forces the model to actually run the code before claiming it's done, which is the cure for false completion claims. The cost is wordier, slower answers.
webapp-testing / mcp-builder / skill-creator (the three official ones): "let the agent open the page and verify your frontend change", "scaffolding for writing an MCP server", and "scaffolding for writing a SKILL.md". Install skill-creator regardless — you will end up writing your own.
Failure modes: seeing "279.8k stars" and installing superpowers to write a 50-line script — mandatory TDD plus two-stage review will cost you an hour for a ten-minute job. Or treating anthropics/skills as an app store and cloning the whole repo: of its 19 skills, algorithmic-art, slack-gif-creator and canvas-design have nothing to do with your work.
These ten don't belong on one leaderboard: different denominators, and the names get copied wrong
Claim: star counts, install counts and editorial picks measure three different things. In the table above, superpowers' stars are six digits and the single-purpose skills' installs are three — that isn't "more popular", it's a different denominator.
Background
Stars count every passer-by on GitHub (anthropics/skills is at about 172.7k per its repo page, 2026-08 — but it is a reference implementation showing how to write skills, not a list of what to install). Install counts count the registered users of one marketplace. "Editor's pick" counts the writer's taste. None of the three is comparable to the others.
And the numbers move. The 764 installs quoted above for code-reviewer come from a leaderboard dated 2026-03; its own skill page showed 1,236 in 2026-08. Up 60% in five months — so any ranking has to be read together with "which pool, which month", or it's noise.
The more practical trap is wrong names: several 2026 roundups call the official skills artifacts-builder and slack-formatter; the repo directory says web-artifacts-builder and slack-gif-creator, and the latter isn't about formatting Slack messages at all — it makes GIFs. A wrong name means your install fails and your agent can't find it.
In practice
Adopt one hard rule: any skill name that goes into a config, gets fed to an agent, or gets passed to a colleague comes from the repo directory or the official marketplace page. Roundups are for discovering candidates, not for copying names. Three questions for any leaderboard: what is being counted, which pool, which month?
Failure modes: writing one marketplace's top entry into a team standard as "the industry leader". Or the reverse — dismissing a skill because it "only has 32 installs", when within its niche that may already be the ceiling.
// 03
Beyond the list: three-minute inspection of any SKILL.md
Claim: Anthropic's "Skill authoring best practices" is written for authors, but every line inverts into a buyer's criterion — use these six on candidates you find beyond the ten above.
Background
The mechanism first: at startup the agent preloads only every skill's name and description into the system prompt; the body of SKILL.md is read only once the skill is judged relevant, and bundled files only on demand — this is progressive disclosure. So the description decides whether it fires, and the length of SKILL.md decides how much context it eats once it does. The official constraints: name ≤ 64 characters (lowercase, digits, hyphens), description ≤ 1024 characters, body ideally under 500 lines.
In practice
Does the description say when to use it: the official requirement is to state both what it does and when to use it, in the third person ("Processes Excel files..." not "I can help you..."). "Helps with code" either never fires or fires everywhere.
Is SKILL.md over 500 lines: over the limit with no file split means the author skipped progressive disclosure, and you pay tokens for unused content on every trigger.
Is the referencing one level deep: SKILL.md → reference.md is fine; reference.md → details.md is not — with nesting the model often skims the first lines only and takes away a partial picture.
Does the degree of freedom match the task: the official metaphor is "narrow bridge over a cliff vs open field". Database migrations need low freedom (a fixed script); code review needs high freedom (a direction). A code review written as twelve rigid steps treats an open field as a narrow bridge.
Are there executable scripts plus a validation loop: deterministic operations belong in a prepared script rather than being improvised by the model — only a script's output is billed, its contents never enter context. Where quality matters there should be a "validate → error → fix → re-run" loop.
Can it name the three concrete failures it fixes: the official method is evals before docs. If this question has no answer, you have no way to tell whether it helps.
The cost of installing too many: context tax, trigger collisions, and things that shouldn't be skills
Claim: the marginal cost of one skill looks like a few dozen tokens of metadata, but the real cost isn't at startup — it's selection. The more skills with overlapping descriptions, the likelier the model picks the wrong one.
Background
Progressive disclosure really does make "install 100 skills" nearly free at startup. But the description matters precisely because the model has to pick one out of hundreds of candidates. Add codex-grade-coding to the table above, plus a homemade "code quality" skill, and you have manufactured a selection problem rather than stacking capability.
The other half of the cost: what you want may not be a skill at all.
Skill = injects knowledge of "how to do this". For tasks with a stable routine that must follow your rules.
Subagent = spawns a context-isolated worker that returns only conclusions. For exploration that generates a lot of intermediate garbage.
MCP server = connects external capability and live data (current docs, a browser, a database). A skill can't teach the model facts it doesn't know; MCP can.
Hooks = "run lint before every commit" should be guaranteed by code; putting it in a skill is praying the model remembers.
In practice
Decision order: must this happen every time → hook; does it need external data or capability → MCP; does it generate bulk intermediate work that shouldn't stay in the main context → subagent; is it just "the model needs to know how" → skill.
Failure modes: turning an API doc into a skill — docs go stale and every trigger costs tokens; that's a job for a docs-retrieval MCP server. Conversely, turning your team's code conventions into an MCP tool is wrong too: that is pure knowledge, so it should be a skill. Also: a third-party skill is someone else's executable instructions. An Agensi skill page will say "Security scanned · verified clean 5 months ago" — a scan five months ago doesn't mean it's clean now. Open the SKILL.md and read it before installing.
// ONE-PAGE BUYING CARD
Start with these three: skill-creator (official — you'll write your own eventually) + code-reviewer or git-commit-writer (whichever you actually do daily) + superpowers (only if your work really is multi-step engineering). Don't install ten at once.
Three minutes before installing: does the description say when to use it, in the third person · is SKILL.md under 500 lines · is referencing one level deep · does the freedom match the task's fragility · is there a validation script · can it name the three failures it fixes.
Three questions for any leaderboard: what is counted? which pool? which month? — and take names from the repo directory, never from a roundup.
Review two weeks later: how many times did it fire? Any misfires? Delete anything that never fired — keeping it only makes your other skills harder to select.
// GLOSSARY
Agent Skill
A folder that must contain SKILL.md (YAML frontmatter + Markdown body), optionally with reference docs and executable scripts. The agent reads it into context on demand to learn "how to do this class of task".
SKILL.md / frontmatter
The main file. Its YAML header requires name (≤64 chars, lowercase + digits + hyphens) and description (≤1024 chars).
progressive disclosure
At startup only every skill's name + description is preloaded; the body is read after triggering, bundled files only when needed, and scripts are executed without their contents entering context. This is why installing many skills doesn't blow up your context.
harness
The shell that runs the agent (Claude Code, Cursor, Codex CLI...): it decides how context is organised, how tools are exposed and how skills are loaded. The same skill can behave differently across harnesses.
marketplace / plugin
Distribution channels for skills. A plugin is the larger unit that can bundle skills + commands + hooks; a marketplace is a directory site listing those packages, official and third-party.
MCP (Model Context Protocol)
An open protocol connecting agents to external tools and data sources. It supplies facts the model doesn't know and actions it can't take — complementary to what a skill supplies.
// FURTHER READING
anthropics/skills · skills directory — the source of every starred entry; the authority for real names and for reading how others write a SKILL.md
obra/superpowers — the repo homepage documents all seven stages and the install command per harness; Skill 2 takes it apart
Agensi · skills directory — source of the single-purpose skills here; each page shows install count, zip download and the date of its security scan