BMAD, Spec Kit, Superpowers, OpenSpec: Which Agent Skill Framework Fits Your Project Size

I planned my last big project up front, before a single line of code existed. The full BMAD process: product brief, PRD, architecture, stories. I slow played the first quarter of the project over about 4 evenings or eight hours, stupidly using Opus to execute the plan. Then I pointed Sonnet at the plan and it built about 75% of the app in one afternoon. A working Electron app, not a demo. Every decision it would have stopped to ask about was already written down somewhere, so it kept going. I am using the app right now to write this post and making notes on the new plugins I’m going to create for it.

Now I want that on purpose, at scale. I have a pile of projects in various states of done, and I want them planned well enough that agents can run them unattended while I do other things, but the projects are not the same. Some are big apps like that one. Some are tiny backend APIs that still need structure. A product brief for a small API is like hiring a general contractor to hang a picture frame.

So which planning framework fits which project? There are a lot of them: BMAD, Spec Kit, OpenSpec, Superpowers, Matt Pocock’s skills, Addy Osmani’s agent-skills, PStack, plus skill catalogs full of more. Instead of guessing, I sent a research subagent out to map the field, the same trick I wrote about in the deep research tools post. Nine candidates I named up front. Sixteen more the research found. This post is what that turned into.

• The Heavyweights: BMAD and PStack
  • BMAD Method
  • PStack
• The Middleweights: Superpowers, Spec Kit, Pocock, and Addy Osmani
  • Superpowers
  • Spec Kit
  • Matt Pocock’s skills
  • Addy Osmani’s agent-skills
• The Lightweights: OpenSpec and the Catalogs
  • OpenSpec
  • The catalogs
• The Ones Research Found
• The Size Chart
• The Gap: Nobody Built the API-Only One
• What I’m Doing With This

The Heavyweights: BMAD and PStack

BMAD Method

BMAD is the one I used, and it covers the widest span of anything in this post: research, product brief, PRFAQ (press-release-plus-FAQ), PRD, UX design, architecture, stories, build, review, retro. It ships persona agents (analyst, architect, dev, PM, product owner, UX designer) and it spells out, better than the rest, when a change deserves the full pipeline and when to skip it. A build session is about 500 changed lines in a handful of files. Trivial edits skip BMAD. PRDs are for when more than one person has to agree.

Install is npx bmad-method install for the stable v6.12. The V7 preview alpha installs differently (npx skills add bmad-code-org/BMAD-METHOD), and the alpha docs warn about breaking changes between updates, so maybe don’t build your whole company’s process on it yet. There are add-ons growing around it: BMAD Loop, which builds, verifies, and retros a whole epic unattended.

The critics do have a point though. People call it cumbersome and rigid, and one vendor benchmark (Uvik’s SDD benchmark, 50 tickets) found spec creation used over 40% of the tokens. It is the heaviest thing here to learn. It worked for me because the project was big enough to need all of it. That is the trick with BMAD: match the ceremony to the project.

PStack

PStack is Lauren Tan’s (poteto) skill set. It lives inside the cursor/plugins repo, works in Claude Code through the plugin marketplace, and its pitch is “write less, but higher quality code.” More than 50 skills, plus a /poteto-mode command that matches your task to one of 23 playbooks: investigation, bug fix, perf, feature, refactoring, prototype, babysit, shipping, autonomous run, orchestrate, autopilot.

The unattended claims are the strongest in the field. The orchestrate playbook runs multi-day fleets of subagents landing stacked PRs, and the README includes the sentence “i’m going to bed. land the stack even if ci flakes.” It splits models by default: grok for code delegates, opus for the hardest changes and prose. It does not do product. No PRD, no market research, no UX phase. It assumes you already know what you are building. Fit: mid to large, experienced-engineer workflow, especially if you use stacked PRs.

The Middleweights: Superpowers, Spec Kit, Pocock, and Addy Osmani

Superpowers

Superpowers calls itself a complete software development methodology: 15 auto-triggering skills, installable from the official Claude marketplace (/plugin install superpowers@claude-plugins-official), supporting about 16 agent harnesses. The flow: brainstorm, git worktree, plan broken into 2-to-5-minute tasks with exact paths and code, subagent-driven execution with a two-stage review, and enforced TDD. It deletes code written before tests, and none of the workflow is optional.

Its README says it is not uncommon for the agent to work autonomously for a couple hours without deviating from the plan. The web-reported downside is the token bill: the workflow spends tokens before any code exists, and users call it bloated and the full loop overkill on a one-file fix. Sweet spot: small backend to mid app. Skip it for tiny edits (its own docs say the same).

Spec Kit

Spec Kit is GitHub’s entry: a Python CLI (uv tool install specify-cli, then specify init my-project --integration copilot) with 30-plus agent integrations. The flow: set a constitution once per project, then per feature you run specify, plan, tasks, implement, and converge until it says “Converged.” The constitution is the interesting part. It is the strongest governance story in the field: org standards, presets, air-gapped support. If your company needs every agent to follow the same rules, this is the one built for that.

Scott Logic put Spec Kit through its paces and found the process rigid, the docs dense, and no qualitative benefit to justify the overhead. (I hit the same wall when I tried Spec Kit on a solo project.) The Uvik benchmark is the useful one: specs help on tickets touching three or more files and do almost nothing for one-to-two-file tickets. That is the thesis of this post in one sentence. Overkill for tiny. Mid to large greenfield, especially with a team.

Matt Pocock’s skills

Matt Pocock’s repo is called “Skills For Real Engineers,” and the README positions against GSD (get-shit-done), BMAD, and Spec Kit, accusing them of owning the process, taking away your control, and making bugs in the process hard to resolve. So: the anti-framework framework. Small composable skills instead of a pipeline. claude plugin install mattpocock-skills@claude-plugins-official or npx skills@latest add mattpocock/skills, then /setup-matt-pocock-skills once per repo.

Its flow is grill (a skill that interrogates you to align), to-spec, to-tickets (tracer-bullet tickets with blocking edges), then implement or implement-spec, with tdd and code-review. The standouts are wayfinder, which plans work bigger than one agent session can hold as a map of decision tickets, and implement-spec, which runs a whole spec on one integration branch with parallel implementer subagents. The human alignment is front-loaded, which is either the point or the annoyance, depending on how much you like being grilled by your own tools.

Addy Osmani’s agent-skills

Addy Osmani’s set is 25 “production-grade engineering skills” covering a full lifecycle: DEFINE, PLAN, BUILD, VERIFY, REVIEW, SHIP. Install with npx skills add addyosmani/agent-skills. It supports Claude Code, Codex, Gemini, Copilot, Kiro, Antigravity, OpenCode, Windsurf, and Cursor. Nine slash commands: /spec, /plan, /build, /test, /constraints, /review, /webperf, /code-simplify, /ship.

/build auto generates the plan and implements every task after one plan approval, each task TDD’d and committed, pausing on failures or risky steps. And it is the only one here with a dedicated security-and-hardening skill. It is modular, so you can take three skills and leave the rest, and it uses progressive disclosure to keep token usage down. Light on research, UX, and prototyping. Fit: tiny to mid, and probably the best general-purpose base in the list.

The Lightweights: OpenSpec and the Catalogs

OpenSpec

OpenSpec is the least ceremony per change in the field. npm i -g @fission-ai/openspec, openspec init, needs Node 20.19 or newer. Its pitch: fluid not rigid, iterative not waterfall, built for brownfield. /opsx:propose creates a change folder with proposal.md, specs/, design.md, and tasks.md. /opsx:apply implements it. /opsx:archive merges the delta specs into the living specs.

The delta spec idea is good: requirements are written as ADDED or MODIFIED with WHEN/THEN scenarios, and the archive step means your specs stay current instead of rotting in a Google Doc. No research, PRD, UX, TDD, review, security, or unattended orchestration. It is a pure planning layer and it knows it. In the Uvik benchmark it merged 42 of 50 tickets against 36 for the control (merged, not necessarily correct). Tiny feature to large brownfield.

The catalogs

Two things get recommended that are not frameworks. Awesome Copilot is GitHub’s community catalog: 222 agents, 192 instructions, 442 skills, 107 plugins by directory count. Awesome Claude Skills is a curated directory of 241 skills in 15 categories. Both are discovery layers. You assemble your own stack out of them, and Awesome Copilot’s README warns you to inspect anything before installing, because it is third-party content. Useful. Not an answer. (If individual skills are the new part here, I wrote the guide I wish I’d had.)

The Ones Research Found

The research dragged in sixteen more. The ones worth knowing:

• gstack is Garry Tan’s setup: 23 role-based slash commands, so your agent can do a CEO review, an eng manager pass, a design review, QA, release management. Aimed at solo founders shipping products. A human drives it.
• GSD Core comes with a warning label. The most-hyped repo in this space, get-shit-done at 64k stars, got archived and moved. (Star counts in this space are glitchy right now, so treat all of them as rough hints.) The interim gsd-2 is also archived. If a blog post recommends GSD, check which repo it actually means before installing anything.
• planning-with-files does one thing: Manus-style persistent markdown plans with session recovery after /clear and compaction, per-turn plan re-injection, and a deterministic completion gate. Works across 60-plus agents. Built for long tasks and crash recovery.
• Ralph loops are a pattern, not a product: loop an agent against a PRD until it is done. The original snarktank/ralph has been stale since February. frankbria/ralph-claude-code is alive and adds “intelligent exit detection,” which is a feature you only need because the naive version never stops.
• cc-sdd is a minimal Kiro-style spec harness (requirements, design, tasks, implement) whose pitch is turning approved specs into long-running autonomous implementation. Tiny, but interesting.
• ECC (Everything Claude Code) is 285k stars of kitchen-sink harness config. It doesn’t give you a process.
• ruflo, formerly claude-flow, does multi-agent swarm orchestration with memory and vector RAG. Huge star count, marketing-flavored README. Treat the claims cautiously.
• claude-task-master, the classic PRD-to-tasks MCP, has not been pushed in about six months. Momentum has moved elsewhere.
• Compound Engineering is Every’s plugin (25k stars) for Claude Code, Codex, and Cursor, built around a plan, work, review, compound loop where the lessons from each cycle feed the next one. It is the sibling of the compound-writing plugin I run in this vault, and the review and research behavior lives inside its skills rather than as standalone agents. Aimed at small teams and mid-size work.
• oh-my-openagent, formerly oh-my-opencode, is a 70k-star orchestration harness that started on opencode, with an “ultrawork” autonomous mode. It orchestrates and doesn’t plan. I use opencode, so I had to look.

A few more deserve one line each. Kiro is AWS’s spec-driven IDE (requirements, design, tasks, review gates), and it’s its own category because it’s a proprietary IDE, not a pack of skills you drop into your agent. Agent OS injects your codebase standards into specs. Conductor does spec, plan, implement for Claude Code and Antigravity. pilot-shell (now QualityLayer) bolts TDD and quality gates onto a spec flow. spec-kitty is Spec Kit with a governance charter. All smaller, all alive, none changed my picks. The list grows faster than I can install them.

The Size Chart

Here is the point of the post, the mapping the research synthesis landed on:

The evidence base up front: one big success of mine, one solo failure, a vendor benchmark, and a subagent’s read of the repos and the web, not twenty-five installs.

• Tiny script or one-file fix: none of them. BMAD’s own docs and Superpowers’ critics agree on this. Skip process, or at most grab a single skill, like Pocock’s tdd or one of Addy’s.
• Small backend/API: OpenSpec, or Addy /spec + /build, or Superpowers, or Pocock’s grill + tdd.
• Mid app: Superpowers, Addy’s full lifecycle, Pocock to-spec/to-tickets, or Spec Kit. BMAD if you actually want the PRD and UX docs.
• Large multi-feature: BMAD plus the Loop add-on, Spec Kit with a constitution, Pocock wayfinder + implement-spec, or PStack orchestrate. OpenSpec Stores (beta) if the problem spans repos.

And the coverage reality check, because stars and READMEs lie by omission: only BMAD covers the full span from research to retro. Only Addy ships a dedicated security skill, as far as I could find. Only Superpowers makes TDD mandatory. Only PStack will orchestrate a multi-day PR stack. OpenSpec covers planning and nothing else.

Y means a dedicated skill or phase, p is partial, and a dash is nothing. Most cells come from reading the repos and docs. A few are inferred from skill lists, because reading every SKILL.md in every repo is a job, not a blog post, so treat the dashes as “I didn’t find it,” not “it can’t.”

And since the first thing I wanted to know was whether anything besides BMAD has a real research component:

• BMAD (bmad-deep-recon): the only one that does real multi-source research. It covers market, domain, technical, competitive, and user-voice research, can run parallel web searches itself, and writes a cited research.md.
• Pocock (research): the runner-up. A background agent investigates a question from primary sources (docs, source, specs, first-party APIs) and writes it up as a Markdown file with citations. Real research, just small.
• Addy (source-driven-development): not open-ended research. It makes the agent follow the official docs for the versions you actually run and cite each decision.
• PStack (investigation playbook): read-only “how and why” digging in your own codebase. That’s code investigation; it never leaves your repo.
• Spec Kit (opt-in assess extension): gathers evidence on users, market, and prior art for a go or kill call. I couldn’t verify how deep it goes.
• OpenSpec (/opsx:explore): a thinking partner that reads your code and compares options. Not research.
• Superpowers: nothing. Brainstorming is the closest it gets.

Security is the other lopsided column. Addy’s security-and-hardening skill threat-models and walks a hardening checklist, but it is guidance, not a scanner. Everything else in the table either has no security lens or I couldn’t confirm one.

The Gap: Nobody Built the API-Only One

Now the finding I ran the research for. Most of my small projects are backend-only APIs, so I had the research ask a question: is there a lightweight framework for API and backend projects? One that skips the UI phases and leans on contract design, security, and API design instead?

The verdict is a gap. Nothing bundles OpenAPI-first contract design, threat modeling against the OWASP API Top 10, data modeling, and test planning into a spec pipeline an unattended agent can execute.

The pieces exist, scattered across repos. wshobson/agents has the closest components: a backend-development plugin, api-scaffolding, backend-api-security agents, and a security-scanning plugin with STRIDE analysis and attack-tree skills. There is a tiny threat-model skill (alpha-omega-security, 59 stars) and an OWASP Top 10 skill (agamm/claude-code-owasp, 388 stars), though that one targets the web Top 10, not the API Top 10. Addy’s set has api-and-interface-design and security-and-hardening, and nothing forces you to install the frontend skill. There are contract-first OpenAPI skills floating around the directories. Nobody glued any of it into a pipeline.

The research even sketched the glue. Eight short phases, each emitting one artifact:

• brief.md: scope, auth model, SLOs
• data-model.md: entities, PII classification, migrations
• openapi.yaml: resources, error model, idempotency, versioning, linted as a gate
• security.md: STRIDE per endpoint, an authz matrix, OWASP API checklist mapped to testable requirements
• architecture.md: one-page ADRs
• test-plan.md: contract tests generated from the OpenAPI spec, authz negative tests
• ops.md: logs, metrics, runbook stub
• tasks.md: vertical slices with acceptance criteria pointing back at the contract and the security rows

Plus a verify skill that cross-checks the plan: every endpoint has an authz row, tests, and tasks.

And yes, an eight-artifact pipeline for small APIs sounds like hiring the general contractor to hang the picture frame. The axis that justifies it is not project size, it is unattended time: an agent running alone for days needs the contract and the security rows written down whether the app is big or small.

The cheapest path is composing Addy’s lifecycle with wshobson’s security pieces and an OpenAPI contract skill, then writing only the glue. Which sounds like the kind of thing I will build at 11 PM some night and then have to write another blog post about.

What I’m Doing With This

The mapping for my own pile: big apps get BMAD, because the last one proved the ceremony pays for itself at that size. Small APIs get OpenSpec or Addy’s /spec + /build until someone builds the API gap pack. Mid-size is the hard call, and right now I would pick Pocock’s grill-first flow or Superpowers, depending on how much I trust myself not to skip tests.

Two caveats before you take any of this as gospel. Everything above traces to a research pass run on 2026-10-16. Stars and push dates come from the GitHub API, the matrix is part inference, and the criticisms are web-reported. And this space mutates monthly. GSD got archived while I was writing this post. Check the repos before you commit to anything.

And the meta point, because it is the actual plan: the research for this post ran unattended, a subagent doing the reading while I did other things. Get every project planned well enough that an agent can execute it without me, then feed the machine. The API gap pack might be the first thing I plan that way. Or it becomes project number sixteen.