Agentic development frameworks compared

An agentic development framework is a packaged methodology for coding agents: a fixed sequence of steps, the artifacts each step leaves, and the skills, hooks or plugins that enforce it. The frameworks fall into three families — spec-first pipelines, discipline bundles and orchestration harnesses — and differ most in ceremony and in always-on context cost.

Your team has a Slack thread arguing Superpowers against Spec Kit against “we tried BMAD once,” and the GitHub star counts are doing the arguing. This page is for the developer choosing a framework and the tech lead or CTO standardising one: it compares them on what they leave behind and what they cost, then outlines a one-feature pilot that settles the argument with evidence.

What you’ll walk away with from this comparison

• The three families and the problem each one solves.
• Two tables covering 16 frameworks: artifacts and approvals, then agent support, context cost, stars and when to avoid each.
• A verified way to measure context cost with claude plugin details.
• The four pilot steps, an audit prompt and the common adoption failures.

Which family of framework solves your problem?

Spec-first pipelines turn intent into reviewed Markdown before any code: Spec Kit, OpenSpec, BMAD, Tessl, Kiro specs and AI-DLC. Reach for one when nobody can say what “done” meant after the fact. See spec-driven frameworks and, for audit trails, enterprise frameworks.

Discipline bundles change how the agent behaves through skills that fire on their own: Superpowers, Matt Pocock’s skills, Compound Engineering, addyosmani/agent-skills, gstack, Ponytail and karpathy-guidelines. Reach for one when the agent skips tests, plans or review. Discipline packs covers pairing them.

Orchestration harnesses add subagents, hooks, memory and loops: GSD Core, Ralph loops, Everything Claude Code (ECC) and the multi-agent harnesses. Reach for one only when you want hours of unattended work and have tests strong enough to stop a bad run. See autonomous loops.

On the autonomy ladder, our reading is: discipline bundles make Level 2 and 3 sessions dependable, spec-first pipelines move your reading from the diff to the spec on the way to Level 4, and orchestration harnesses assume Level 4 — a written spec, a stop condition and tests you trust.

How do the frameworks compare?

What each framework leaves and who approves it

“Ladder / stage” is our reading of the autonomy ladder level the framework assumes and the lifecycle stages where its artifacts appear.

Framework	Family	Artifacts it leaves	Human gates	Ladder / stage
Superpowers	discipline	design doc, plan	design and plan approval	L2–3 / plan, build
Matt Pocock’s skills	discipline	spec, tickets	alignment interview	L2–3 / plan
Everything Claude Code	orchestration	none required	per command	L3–4 / build, automate
karpathy-guidelines	discipline	none	none	L2–3 / build
Ponytail	discipline	none	none (levels)	L2–3 / build
Spec Kit	spec-first	.specify/, specs/ per feature	after every step	L4 / plan
gstack	discipline	design doc, test plan (in ~/.gstack/projects/), QA reports	per role command	L2–3 / plan, test, ship
addyosmani/agent-skills	discipline	spec, plan	per phase command	L2–3 / plan to ship
OpenSpec	spec-first	openspec/changes/, living openspec/specs/	proposal review	L4 / plan
BMAD Method	spec-first	PRD, architecture, stories	per document	L4 / plan
Compound Engineering	discipline	plans, docs/solutions/	brainstorm and plan	L3 / plan, ship
Ralph loop (ralph-loop plugin)	orchestration	plan file, git history	none inside the loop	L4–5 / automate
GSD Core	orchestration	.planning/ (roadmap, state, plans)	discuss and acceptance	L4 / plan, automate
AI-DLC (AWS Labs)	spec-first	state file, append-only audit trail	after every stage	L4 / plan
Tessl spec-driven-development tile	spec-first	.spec.md files linked to tests	requirement gathering	L4 / plan, test
Kiro specs	spec-first	.kiro/specs/<feature>/ requirements, design, tasks	per document	L4 / plan

Where it runs, what it costs and when to avoid it

Stars come from the repository pages, read on 2026-09-26; they measure attention, not use. Always-on cost is what the plugin adds to every Claude Code session, as projected by claude plugin details on Claude Code 2.1.283 on the same date. “n/a” means the framework installs as project files, a Git clone or a separate product, not a measured plugin.

Framework	Claude Code / Codex / Cursor	Always-on cost	Stars	Avoid it when
Superpowers	yes / yes / yes	~838	291.7k	trivial edits, no tests
Matt Pocock’s skills	yes / yes / yes	~1,609	269.8k	product owners must approve a spec trail
Everything Claude Code	yes / yes / yes	~41,515	268k	you will not prune it
karpathy-guidelines	plugin / CLAUDE.md copied to AGENTS.md / Cursor rule	n/a (not measured)	215.2k	you need a workflow, not behavioural rules
Ponytail	yes / yes / yes	~983	146.1k	you want it to decide scope, not size
Spec Kit	yes / yes / yes	n/a (10 project skills)	138.9k	small brownfield changes
gstack	yes / via ./setup --host / via ./setup --host	n/a (Git clone)	134.2k	you already have a /review workflow
addyosmani/agent-skills	yes / yes / yes	~3,620	99.1k	you run another pack’s /review or /ship
OpenSpec	yes / yes / yes	n/a (6 project skills)	70.4k	you need heavy governance
BMAD Method	yes / yes / yes	~1,676	53.5k	solo small features
Compound Engineering	yes / yes / yes	~2,989	25.3k	prototypes, or nobody curates learnings
Ralph loop	Claude Code plugin only	~84	21.9k (snarktank/ralph)	no test oracle, secrets on the host
GSD Core	yes / yes / yes	~10,700	9.9k (archived original 64.5k)	context-sensitive sessions
AI-DLC	yes / yes / yes	n/a (native CLI)	4.8k	you do not need an audit trail
Tessl tile	via Tessl CLI	n/a (Tessl tile)	54 (tile repo)	you want no proprietary binary in the toolchain
Kiro specs	no / no / no (Kiro IDE and CLI only)	n/a (built into Kiro)	n/a (product)	your team works in Claude Code, Codex or Cursor

The Kiro and Tessl rows rest on their vendors’ documentation, which we could not run here; check both before a pilot. Cursor support comes from each project’s README. For one rules file across agents, see rules sync.

The two numbers that mislead

Stars and cost point in opposite directions. ECC has the third-most stars and costs about 50 times what Superpowers does in every session. GSD Core’s 144 skills are mostly duplicates (plan-phase and gsd-plan-phase both ship), which roughly doubles its listing cost on the plugin path.

When should you use no framework?

Skip frameworks for one-line fixes, throwaway spikes and repositories without tests. A framework adds steps, not a test oracle. If the agent cannot run a suite that fails on a wrong answer, start with a short CLAUDE.md or AGENTS.md, acceptance criteria and a test gate.

Measure two frameworks’ context cost before you choose

claude plugin details prints a plugin’s components and projected token cost. Install the candidates into a throwaway config directory so your real setup stays untouched.

# Terminal. A scratch config dir keeps ~/.claude clean.
export CLAUDE_CONFIG_DIR="$(mktemp -d)"
claude plugin marketplace add anthropics/claude-plugins-official
claude plugin marketplace add EveryInc/compound-engineering-plugin
claude plugin install superpowers@claude-plugins-official
claude plugin install compound-engineering@compound-engineering-plugin
claude plugin details superpowers
claude plugin details compound-engineering

Expected output, trimmed (Claude Code 2.1.283, 2026-09-26):

superpowers 6.4.1
  Skills (15)  brainstorming, ... writing-plans, writing-skills
  Hooks (1)  SessionStart  (harness-only — no model context cost)
Projected token cost
  Always-on:   ~838 tok   added to every session
  subagent-driven-development    ...    ~11.8k
  brainstorming                  ...     ~6.3k

compound-engineering 3.29.0
  Skills (36)  ce-brainstorm, ... lfg
Projected token cost
  Always-on:   ~2,989 tok   added to every session

The numbers drift slightly between releases of Claude Code and of each plugin.

Always-on tokens are paid in every session; on-invoke tokens each time a skill fires. Superpowers is cheap to keep installed, but its subagent-driven-development skill costs about 11.8k tokens a run. The official marketplace pins a commit, so it installed Superpowers 6.4.1 while the author’s repository was on 6.4.2.

Codex and Cursor have no equivalent we could verify: codex plugin in codex-cli 0.157.1 offers add, list, marketplace and remove, and no cost report. There, compare the context meter in a fresh session before and after enabling the framework. The context cost page explains what that overhead does to long sessions.

Pilot a framework on one feature

The pilot is the bake-off protocol at framework scale; the scorecard and decision rule live in pilot design.

1. Pick one framework for the failure you are fixing, at most two, never two from the same family.

2. Install it at project scope on a branch. In Claude Code, --scope project writes the marketplace and plugin into .claude/settings.json; commit it.

   Claude Code

   claude plugin marketplace add EveryInc/compound-engineering-plugin --scope project
   claude plugin install compound-engineering@compound-engineering-plugin --scope project
   claude plugin details compound-engineering

   Codex

   codex plugin marketplace add EveryInc/compound-engineering-plugin
   codex plugin add compound-engineering@compound-engineering-plugin

   Codex has no project scope for plugins (codex-cli 0.157.1); the install is user-wide, so remove it after the pilot with codex plugin remove compound-engineering@compound-engineering-plugin.

   Cursor

   /add-plugin compound-engineering

   Type it in the Agent chat. The command comes from the project’s README, not from a test.

3. Run one real feature through it, with acceptance criteria written as tests first, and the same feature without the framework on a baseline branch.

4. Score both branches the same way, then adopt or uninstall. The tech lead reads the scores and the evidence bundle, not the diff; the framework’s documents are inputs, the tests are the proof.

Copy-paste prompt: audit the frameworks you already have installed

Run `claude plugin list`, then `claude plugin details <name>` for every enabled plugin.
Build a Markdown table: plugin, version, skills, agents, hooks, always-on tokens, and the
three most expensive on-invoke components. Mark any two plugins that both ship a planning
or review workflow (for example two `/review` commands) as a collision. Recommend which
to disable so that only one process framework stays enabled, and give the exact
`claude plugin disable` commands. Do not run the disable commands yourself.

What goes wrong when teams adopt a framework?

Failure	What you see	Recovery
Two process frameworks at once	Two /review commands, conflicting plans, doubled always-on cost	Keep one per family; pair a process pack only with Ponytail
Treating artifacts as proof	A beautiful spec, and a bug in production	Gate the merge on tests and acceptance criteria
Installing the whole bundle	Sessions start tens of thousands of tokens down (ECC ~41,515)	Measure with claude plugin details; disable what you do not use
An unbounded loop	A Ralph loop runs all night on a goal it cannot meet	Pass --max-iterations, run in a sandbox, prefer built-in /goal for one session

Where to go next with frameworks

Spec-driven frameworks compared Spec Kit, OpenSpec, BMAD and Superpowers on the same feature.

Discipline packs Pocock's skills, gstack, agent-skills, Ponytail and ECC, and how to pair them.

Autonomous loops GSD Core, Ralph loops and /goal for hours of unattended work.

Plugins How plugins install, update and are pinned in each agent.

The artifact chain Where specs, plans and evidence sit between intent and release.

The ecosystem The six layers around the agent, frameworks included.