Superpowers at 296k stars: I read all 15 skills, and the whole methodology is 170 KB of markdown

Superpowers, the skills framework from Jesse Vincent (obra), turns one year old this Friday. The GitHub repo was created on October 9, 2025, and this week the commentary anointed it "the methodology layer for AI coding". Most of those takes quote a star count in the low hundred thousands. I pulled the GitHub API today instead: 296,175 stars, 26,439 forks, 1,094 watchers, MIT licensed. Then I cloned it at v6.4.2 and read every skill file. The gap between what people say about it and what ships is the interesting part.

The number, measured today

At my reading on October 7, 2026, api.github.com/repos/obra/superpowers reports 296,175 stars, 26,439 forks, and a last push on October 6. The repo was created October 9, 2025, so it hits its first birthday two days after this post. The editorials circulating this week still cite roughly 113k stars, which tells you how fast the thing is moving and how stale a star count goes in a quarter. Stars are a lagging indicator either way. What convinced me to look closer is simpler: a pile of markdown files with no runtime and no dependencies does not pass 296k stars unless it changes how someone's workday feels.

What ships: 15 skills, 170 KB

I cloned the repo at tag v6.4.2 (committed September 25, 2026) and counted: 15 SKILL.md files, 170,125 bytes total. The biggest ones:

• subagent-driven-development at 32,577 bytes, the largest skill in the set
• writing-skills at 26,623 bytes, their guide for authoring new skills
• executing-plans at 20,405 bytes
• brainstorming at 17,548 bytes
• writing-plans at 10,335 bytes
• test-driven-development at 9,578 bytes
• systematic-debugging at 9,465 bytes

That is the entire product. No model, no server, no package dependencies (the zero-dependency rule is enforced in the contributor guidelines). It is instructions all the way down, and the instructions are opinionated in a way most CLAUDE.md files never manage to be.

How it takes over your session

The load-bearing piece is the using-superpowers bootstrap. Its description says it all: "Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions". Once the bootstrap runs at session start, skills trigger on their own. You do not invoke TDD, the situation invokes it.

The maintainers take auto-triggering seriously enough to gate new harness integrations on it. From the contributor guidelines: open a clean session, send exactly Let's make a react todo list, and a working integration must fire the brainstorming skill before any code gets written. If brainstorming does not auto-trigger, the integration is rejected. The README currently carries install sections for 16 harnesses: Claude Code, Cursor, Codex App and CLI, Gemini CLI, GitHub Copilot CLI, OpenCode, Antigravity, Devin CLI, Factory Droid, Grok Build CLI, Kimi Code, Pi, Qwen Code, and a couple more.

The Iron Law

The test-driven-development skill is the tightest 9.5 KB in the repo. Its core rule, in a code block, uppercase:

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

The enforcement clause right below it reads: "Write code before the test? Delete it. Start over." And then the part that actually has teeth: no keeping the deleted code as "reference", no "adapting" it while you write tests, delete means delete. There are exceptions (throwaway prototypes, generated code, configuration files), and the skill requires asking what it calls your human partner before taking one. That phrase is deliberate; the guidelines state the terminology is not interchangeable with "the user", because the skill is written to shape how the agent treats you.

The AGENTS.md is the best file in the repo

The contributor guidelines open with a warning to AI agents: this repo has a 94% PR rejection rate, and maintainers close slop PRs within hours, "often with public comments like 'This pull request is slop that's made of lies.'" Every PR must disclose the model, harness, harness version, and installed plugins that produced it, or state it was written by hand. Agent-generated contributions are held to a different bar than human ones, openly.

Two policies stood out to me as a config person. First: "Skills are not prose - they are code that shapes agent behavior." Skill changes require eval evidence, run through their superpowers-evals harness, where a CLI called Quorum drives real coding agents through a Gauntlet QA agent and grades them against scenario acceptance criteria. Second: project-specific skills are rejected from core outright. General-purpose only, everything else belongs in your own plugin.

Install paths and one telemetry detail

On Claude Code it is in the official plugin marketplace:

/plugin install superpowers@claude-plugins-official

In Cursor Agent chat:

/add-plugin superpowers

One detail worth knowing before you install: brainstorming's optional visual companion loads a logo image from the maintainers' website, and that request carries your Superpowers version. No project data, no prompts, no clicks, per their README. It is opt-out telemetry, and the opt-out is an environment variable:

export SUPERPOWERS_DISABLE_TELEMETRY=1

It also honors DISABLE_TELEMETRY and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC if you already set those.

What to steal for your own config

You do not have to adopt the whole methodology to learn from it. Three patterns are worth copying tonight.

First, small named skills with entry conditions beat a dumping-ground rules file. Every skill frontmatter here states when it applies ("Use when implementing any feature or bugfix, before writing implementation code"), which is what makes auto-triggering possible. A CLAUDE.md that is 200 lines of "don't do X" has no entry conditions, so nothing fires at the right moment. If you want version-pinned, pre-audited kits in this shape instead of hand-rolling, that is literally what we sell at AgentConfig Studio, $29.

Second, write yourself an acceptance test sentence. Pick one canonical prompt, like their Let's make a react todo list, and check after every config change that the right behavior still fires. It is a ten-second smoke test for prompt infrastructure.

Third, treat process as the lever, not the model. The measured versions of this argument keep landing: NVIDIA measured coding agents at 19% without a spec file and 100% with one, and Hugging Face measured the same model at 33% or 62% depending on the harness. Superpowers is the same bet, shipped as 170 KB of opinion.

Where I would not use it

Honest limits from reading, not from benchmarking it for a quarter. The ceremony is real: a one-line fix routed through brainstorming, a git worktree, a written plan, and subagent review is a lot of process for a CSS tweak, and the workflow skills do not obviously scale down. I measured bytes on disk, not context-window cost at runtime, so I am not claiming it is free to load; the bootstrap indexes skills and loads bodies on trigger, but your harness's plugin loading is what actually decides. The skill content is tuned against real agent behavior in their eval harness, and it grew up on Claude Code, so expect the tuning to be least surprising there and more experimental on the smaller harnesses. And if you want project-specific skills, you will write them yourself, since core rejects them by design. That rejection policy is not a bug, it is why the thing stays general enough to hit 296k stars in a year.

Sources: obra/superpowers on GitHub (star and fork counts from the GitHub API, October 7, 2026; skill counts and file sizes from a clone at v6.4.2), the original release announcement, and the repo's own README and AGENTS.md. The Next.js sample kit mentioned above is free here.