Nine Agent Frameworks and What I Borrow from Them
A source-level review of nine agent frameworks: what they mechanically do, the conventions they share, and the case for adopting their ideas in a custom setup.
Start with obra/superpowers. Jesse Vincent's agentic skills framework for Claude Code.
Superpowers has attracted substantial attention. Repository popularity is useful discovery information, but it is neither a measure of effectiveness nor a substitute for inspecting the implementation.
I have never used it. I have never used any of them. I run a heavily customised setup of my own design, and my justification has always been the same one sentence: I know exactly what mine does.
That's a comfortable position. It's also the kind of position that quietly rots if you never test it. So I spent the morning actually reading the ecosystem — the source, not the marketing — and this is what's in there, the recurring ideas I found, and what I'm stealing without installing anything.
First, the Scale of This Thing
These projects serve different roles. The table compares those roles rather than presenting historical star and fork counts without a preserved measurement snapshot.
| Project | What it is |
|---|---|
| obra/superpowers | Skills framework + enforced development method |
| github/spec-kit | Spec-driven development toolkit |
| Fission-AI/OpenSpec | Change-local specs and archival |
| hesreallyhim/awesome-claude-code | Curated list — not a framework |
| bmad-code-org/BMAD-METHOD | Agile-org-as-personas methodology |
| eyaltoledano/claude-task-master | Persistent task graph layer |
| oraios/serena | Semantic code retrieval via MCP |
| SuperClaude-Org/SuperClaude_Framework | Command and persona configuration |
| buildermethods/agent-os | Workflow and standards layer |
The table includes both executable tooling and curated lists. Those are different products: a list helps discovery, while a framework supplies a workflow or runtime. Popularity alone does not make them interchangeable.
What Superpowers Actually Is
Mechanically it is unglamorous, and that's the point. It's Markdown. A skill is a directory containing an instruction file plus any scripts it references. There is no runtime, no model wrapper, no clever inference.
It installs through Anthropic's own plugin marketplace:
/plugin install superpowers@claude-plugins-official
# Alternative: register the project's marketplace, then install
# the plugin using the identifier documented by that marketplace.
/plugin marketplace add obra/superpowers-marketplaceWhat you get is a library of skills that trigger on context rather than on request — the agent is instructed to check whether a skill applies before doing anything, load it, and follow it. The README is blunt about the intent: "Mandatory workflows, not suggestions."
The enforced sequence:
| Phase | What it does |
|---|---|
| 1. Brainstorming | Refines a rough idea through questions, explores alternatives, presents the design in sections for approval. You do not get to code yet. |
| 2. Git worktree | Isolates the work in its own branch and directory before anything is written |
| 3. Writing plans | Decomposes into tasks of 2–5 minutes each |
| 4. Subagent-driven development | A fresh subagent per task, each passed through a two-stage review |
| 5. Test-driven development | Strict RED-GREEN-REFACTOR — write the failing test, watch it fail, then write the minimum code |
| 6. Code review | Checked against the plan, issues reported by severity |
| 7. Verification before completion | Fresh evidence required. Not "this should work" |
| 8. Branch completion | An explicit merge-or-PR decision rather than an ambiguous working state |
The stated philosophy is four lines: test-driven development, systematic over ad-hoc, complexity reduction, evidence over claims. The pitch is that agents can work autonomously for a couple of hours without drifting off the plan.
Superpowers is arguing that model capability is not what is failing you. The failure is uncontrolled process: coding before the problem is defined, untested assumptions, vague plans, and agents declaring victory without ever running anything.
I think that diagnosis is largely correct. Almost every bad session I have had was a process failure, not an intelligence failure. Where I part company is on how much ceremony is the right response.
These Are Not All the Same Thing
The single most useful thing to come out of the morning was realising that "Claude Code framework" is a label covering at least seven different categories of software, which people compare as though they were competitors. A prompt library cannot give you process isolation. An orchestration runtime does not produce good specifications. A GUI that launches six agents is not a multi-agent strategy — it's six terminals with better ergonomics.
| Category | What it actually does | Examples |
|---|---|---|
| Skill & prompt libraries | Reusable instruction bundles that beat ad-hoc prompting | Superpowers, SuperClaude, Anthropic Skills |
| Workflow methodologies | Prescribed phases and gates to stop agents jumping straight to code | Superpowers, BMAD-METHOD, Agent OS |
| Spec-driven systems | Repo files holding requirements, plans and change history — intent that survives compaction | spec-kit, OpenSpec, cc-sdd |
| Orchestration runtimes | A coordinator dispatching multiple agents and aggregating results | claude-flow |
| Task-management layers | Machine-readable task graphs that make long work resumable | claude-task-master |
| Context & memory | Retrieval and project memory so agents get relevant context without the whole repo | Serena |
| GUI runners | Running several agents without terminal chaos | Conductor, Crystal |
| Curated lists | Discovery only. A directory, not a framework — evaluate accordingly | awesome-claude-code |
The other four worth knowing
| Project | The mechanics | Its real weakness |
|---|---|---|
| GitHub spec-kit | After installing Specify CLI, run its documented project-initialization command to scaffold the .specify/ workspace and agent commands. Installation and project initialization are separate steps. | Synchronisation. Specs, tasks, tests and code can each claim authority. Unless completion updates the right artifact, the repo accumulates beautifully structured lies. |
| BMAD-METHOD | A simulated product org — analyst, PM, architect, scrum master, dev, QA — with templates carrying an idea through requirements, architecture, stories and QA. | Cargo cult. A role prompt does not create independent expertise, and passing text between personas can amplify one early false assumption. |
| claude-task-master | Turns a PRD into a persistent task graph with dependencies, complexity scores and a next-task operation. CLI or MCP. | It inherits every omission in the input, and agents can spend more time maintaining task metadata than shipping. |
| Serena | An MCP server for semantic code navigation — symbol lookup, references, structural summaries — instead of pasting whole files. | It is a retrieval layer, not a method. Solves a real problem, imposes no discipline. |
Recurring Workflow Ideas
This is the section that changed my mind about the exercise being worthwhile.
These are recurring ideas to evaluate in workflow tools; they are not requirements implemented by every project listed here.
| Convention | Why it can help |
|---|---|
| Plan before code | Unconstrained agents collapse problem definition and implementation into one fluent guess |
| Persist intent in the repo | Chat history is an execution trace, not durable project state. Specs and plans survive compaction; conversations don't |
| Decompose aggressively | Small tasks give clearer completion conditions and shrink the blast radius of a misunderstanding |
| Fresh context for bounded work | Subagents help less because they're "specialists" and more because they get a clean, limited problem. Context isolation is a correctness tool |
| Separate implementation from review | Asking a context to reconsider its own work produces anchoring. A second, independent pass is materially different |
| Verify with evidence | A completion claim must name and run the tests. "This should work" is not verification |
| Isolate concurrent work | Worktrees don't solve semantic conflicts but they stop agents trampling each other's filesystem |
| Curate memory, don't accumulate it | Successful systems keep a compact curated memory. Unsuccessful ones dump an ever-growing transcript into the prompt |
| Human approval at high-leverage points | Approving a plan is far cheaper than reviewing a thousand lines built on the wrong premise |
These ideas give me useful questions to ask of a workflow. Compare the actual implementations and decide which constraints your own setup needs; a directory, a retrieval tool and an orchestration runtime solve different parts of the problem.
The Honest Case Against Me
Let me steelman the thing I don't do, because "I know what mine does" can very easily become a flattering story.
| Argument | The uncomfortable version |
|---|---|
| Scar tissue | Someone else already discovered that agents skip the failing-test step, claim verification from stale output, and lose task state after compaction. Mature instruction wording contains fixes for bugs I have not hit yet. |
| Upgrade path | Model behaviour changes. A prompt that reliably triggered tool use last year can produce ritual this year. Maintaining that compatibility is real work I am doing alone. |
| It isn't teachable | My system is efficient partly because it lives in my head. That is not a team platform. A named method lets someone else install the same components and argue with me in shared language. |
| Discovery | Fresh-agent review, worktree isolation, repo constitutions, explicit clarification passes — each obvious after seeing it. I would not have invented all of them. |
| Opportunity cost | Building agent infrastructure is seductive because every improvement feels multiplicative. Sometimes installing a good-enough framework is the disciplined choice, not the lazy one. |
And the Case For Doing It Myself
The case for a smaller stack depends on what it loads, how it behaves and the maintenance it requires. Those properties can be measured in the actual client.
| Argument | Why it holds |
|---|---|
| Causality | When something behaves strangely under a layered framework, was it the base model, global instructions, project rules, an auto-selected skill, a hook, an MCP tool description, or the orchestrator? A small custom stack is a tractable one. |
| Generic gates mismatch real repos | A monorepo with hermetic tests and mandatory ownership checks needs different gates from a mobile prototype. Framework defaults encode the author's development culture and then present it as universal method. |
| Version churn | Command names, directory conventions and orchestration APIs change independently of your application. Pin and forfeit improvements, or track latest and import behavioural changes. |
| Ceremony has a floor | The full Superpowers sequence on a three-line fix is absurd. Gates that can't be skipped are a feature on a feature and a tax on a typo. |
| Building it IS the understanding | Writing my own planning gate forced me to define what a useful plan contains. Implementing task claims taught me where concurrency actually breaks. That understanding isn't overhead next to the value — for an AI-native engineer it may be the value. |
One caveat I'll hold myself to: the strongest custom setup is not a pile of personal prompts. It's a small, inspectable framework built for one environment, with explicit interfaces and its own tests. If mine isn't that, the argument doesn't apply to me.
What I'm Stealing Without Installing Anything
This is the actual output of the morning. Nine techniques, each portable into a custom setup, none requiring you to adopt the surrounding mythology.
| From | Steal this | How |
|---|---|---|
| Superpowers | Verification before completion | Rule: every completion report must include the command run, its exit status, and a one-line interpretation. No inferring success from reading the code. |
| Superpowers | Two-stage review | One fresh context gets the spec and the diff and answers only does this meet requirements. A second gets the diff and conventions and answers is this correct and maintainable. Asking both at once invites trading one against the other. |
| spec-kit | The repository constitution | A short versioned file of non-negotiables — architecture constraints, test expectations, forbidden shortcuts. Load it during spec and review, not into every trivial interaction. |
| OpenSpec | Change-local specs with archival | Each substantial change gets its own directory: proposal, requirements delta, plan, outcome. After shipping, merge durable decisions into canonical docs and archive the rest. |
| BMAD | Artifact contracts, not role-play | Define what a PRD or implementation story must contain — open questions, acceptance criteria. You don't need six named personas to fill them in. |
| claude-task-master | Persistent task state | Task IDs, dependencies, status and verification criteria in a machine-readable file. Workers claim before executing and update only on evidence. |
| claude-flow | Topology discipline | Parallelise only independent leaves of the task graph. One coordinator owns shared decisions and synthesis. Don't let every worker rewrite the plan. |
| Serena | Semantic retrieval over file dumps | Expose symbol lookup, references and structural summaries as tools. Keep retrieved context attributable so the agent can tell repo facts from its own remembered summary. |
| SuperClaude | A small command vocabulary | specify, plan, implement, review, verify. Each declaring inputs, outputs, allowed tools and completion conditions. Far easier to debug than one omnipotent prompt. |
Where This Goes
Anthropic shipping official Skills, Plugins and a marketplace absorbs the packaging layer. Discovery, installation, namespacing, updates, hooks, distribution — those are natural vendor features, and Superpowers already installs through the official marketplace. MCP does the same for tool exposure: "our framework can call a database" stops being an advantage once every client speaks the protocol.
Parallel sessions, worktrees, background execution, diff views and resumability will drift down into the products too. Launching several agents will stop being distinctive.
What survives is the layer containing judgment. A methodology that encodes how your company designs migrations or reviews security-sensitive changes. A context system that understands your ownership and build structure. An orchestration policy that knows which tasks are safely parallel in your architecture.
The investment rule falls out of that: don't build proprietary machinery for commodity installation, generic protocols or terminal multiplexing. Invest in inspectable workflow definitions, domain-specific gates, evaluation, durable project memory, and verification that produces evidence.
So — Do I Install It?
No. And I'm more comfortable with that than I was this morning, for a better reason than I had this morning.
These projects contain useful process ideas: explicit requirements, bounded work, independent review and evidence before completion. Their value should be assessed through those mechanisms and workload results, not a star-count threshold.
The reason is that the value in these frameworks is the ideas, and ideas are free. The packaging costs context, opacity and version churn. The nine techniques in the table above are the entire payload. I can implement every one of them in my own system, in my own vocabulary, tuned to my own repositories, and still be able to explain what every instruction in my stack is doing and why.
But the position only holds under one condition, and it's worth stating plainly because it's the part that's easy to skip:
Refusing the package can be rational.
Refusing the accumulated lessons is not.
I've been running my own setup for long enough that I'd stopped reading anyone else's. That was the actual mistake — not the building. Reviewing another framework was worth a morning, and I came out with nine things to implement and a much sharper account of why I'm not installing the thing that gave them to me.
