Md Jamilur Rahman

Posted on Jul 18

Superpowers vs Agent Skills vs Pocock: Three Philosophies of AI Coding Workflows

#ai #llm #agentskills #opensource

Every few months, a new framework appears promising to make AI coding agents write better code. Three have risen above the noise in 2025 and 2026: Superpowers by Jesse Vincent, Agent Skills by Addy Osmani, and Matt Pocock's Skills. As of July 2026, their combined GitHub stars exceed 350,000.

But star counts do not tell you what these frameworks actually do, how they differ architecturally, or which one fits your work. After reading all three repos, their launch posts, their own comparison docs, and community discussions, here is what I found.

The Shared Problem They All Solve

AI coding agents default to the shortest path. They skip specs, rush to code, avoid writing tests, and skip security review. This is not a model limitation. The model is optimized to produce output quickly.

The result is code that looks correct but skips the practices that make software reliable. Senior engineers learned decades ago that process matters: spec before code, tests before features, review before merge. AI agents have not learned this, and so far no model improvement has taught it, because the model is optimizing for the wrong thing.

All three frameworks solve this by encoding engineering process into skills: structured markdown instructions that the agent reads and follows. The difference is which process, how strictly, and what trade-offs each one makes.

Superpowers: The Autonomous Pipeline

Created by: Jesse Vincent (obra), October 2025
Repo: github.com/obra/superpowers
Philosophy: Deep upfront reasoning, then hands-off execution

Vincent describes Superpowers as "a complete software development methodology" for coding agents. It is not a loose collection of tips. It is a strict pipeline that activates automatically the moment you start building something.

The pipeline has six stages:

1. Brainstorming. The agent does not jump to code. It asks questions, explores alternatives, and produces a design document. Vincent described this in his launch post as "teasing a spec out of the conversation."

2. Worktree isolation. After design approval, it creates a git worktree. This is a real architectural decision: parallel tasks get isolated workspaces and cannot clobber each other.

3. Writing plans. The design gets broken into small tasks, each 2 to 5 minutes of work. Vincent describes these plans as "clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow." Every task has exact file paths, complete code, and verification steps.

4. Subagent-driven development. This is Superpowers' signature feature. Instead of one agent doing everything, it dispatches a fresh subagent per task. A task reviewer then checks spec compliance and code quality before closing. Critical issues block progress.

5. Test-driven development. Strict RED-GREEN-REFACTOR enforced. Write a failing test, watch it fail, write minimal code, watch it pass, commit. Code written before tests gets deleted.

6. Code review. Between tasks, it reviews against the plan and reports issues by severity.

What makes Superpowers distinctive is autonomy. Vincent designed it for situations where you want to hand off a large chunk of work and come back later to a reviewed result. The subagent architecture means the main agent is managing workers, not doing the implementation itself. The trade-off is process weight: the full pipeline feels heavy for a one-line bug fix.

Agent Skills: The Full Lifecycle System

Created by: Addy Osmani, February 2026
Repo: github.com/addyosmani/agent-skills
Philosophy: Encode the entire SDLC with adversarial guards

Where Superpowers goes deep on the inner build loop, Agent Skills goes broad across the entire software development lifecycle. It packs 24 skills across six phases:

Define: interview-me, idea-refine, spec-driven-development
Plan: planning-and-task-breakdown
Build: incremental-implementation, test-driven-development, context-engineering, source-driven-development, doubt-driven-development, frontend-ui-engineering, api-and-interface-design
Verify: browser-testing-with-devtools, debugging-and-error-recovery
Review: code-review-and-quality, code-simplification, security-and-hardening, performance-optimization
Ship: git-workflow-and-versioning, ci-cd-and-automation, deprecation-and-migration, documentation-and-adrs, observability-and-instrumentation, shipping-and-launch

Eight slash commands map to lifecycle phases: /spec, /plan, /build, /test, /review, /code-simplify, /webperf, /ship. A /build auto mode runs a whole approved plan in a single pass.

Two design choices make this framework different from the others.

Anti-rationalization tables. Every skill includes a "Common Rationalizations" table listing excuses agents make to skip steps, each with a rebuttal. Here is the real table from the TDD skill file:

"I'll write tests after the code works" — You won't. Tests written after the fact test implementation, not behavior.
"This is too simple to test" — Simple code gets complicated. The test documents the expected behavior.
"Tests slow me down" — Tests slow you down now. They speed you up every time you change the code later.
"I tested it manually" — Manual testing doesn't persist. Tomorrow's change might break it with no way to know.
"The code is self-explanatory" — Tests ARE the specification. They document what the code should do, not what it does.
"It's just a prototype" — Prototypes become production code. Tests from day one prevent the "test debt" crisis.

This is adversarial by design. It assumes the agent will try to cut corners and preempts each rationalization with a rebuttal baked into the skill itself.

Parallel review personas. The /ship command does not just run one review. It fans out four specialist reviewers independently: code-reviewer, security-auditor, test-engineer, and web-performance-auditor. Each runs its own analysis, then results merge into a go/no-go decision.

Osmani explicitly grounds the skills in Google's engineering practices. The README references Hyrum's Law in API design, the Beyonce Rule in testing, Chesterton's Fence in simplification, and trunk-based development in git workflow. These come from Software Engineering at Google and Google's engineering practices guide.

Agent Skills is also the only framework of the three that ships an eval framework in the repo. It runs in CI and checks that skills route correctly, descriptions carry the vocabulary users actually say, and no two skills collide on routing. If a skill stops triggering, CI catches it rather than you discovering the problem silently later.

Matt Pocock's Skills: The Requirements-First Toolkit

Created by: Matt Pocock (Total TypeScript), 2026
Repo: github.com/mattpocock/skills
Philosophy: Fix requirements first, keep skills composable, do not own the process

Pocock's approach is deliberately the opposite of the other two. His README opens with a direct critique of process-owning frameworks: "Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve." (GSD, BMAD, and Spec-Kit are other AI development frameworks that impose rigid end-to-end workflows.)

His skills are "designed to be small, easy to adapt, and composable."

The signature feature is the grilling primitive. Instead of letting the agent guess what you want, grill-me asks one question at a time, walks each branch of the design tree resolving dependencies in order, and refuses to proceed until you confirm a shared understanding. It prefers reading the codebase over asking when it can.

His TDD skill is heterodox compared to the other two. He argues that "refactoring is not part of the loop" and belongs in code review instead. This is a genuine philosophical split: Superpowers and Agent Skills bundle refactoring into TDD, Pocock separates it.

Pocock also makes a deliberate split between user-invoked and model-invoked skills, treating agent context as a scarce budget. Not every skill should be in context at all times.

The Real Architectural Divide

After studying all three, the core difference is not "fast versus safe" or "better versus worse." It is a spectrum from composable to opinionated.

At the composable end sits Superpowers and Pocock's skills. You can drop a Superpowers brainstorming subagent into your own custom skill. You can use its worktree isolation without adopting its TDD enforcement. Pocock's skills are explicitly built to be small, adaptable modules. Both treat their skills as building blocks you assemble into your own workflow.

At the opinionated end sits Agent Skills. The 24 skills, anti-rationalization tables, review personas, eval framework, and reference checklists are deeply interconnected. You adopt the system or you do not. This is not a flaw. It is a deliberate trade-off: you get a complete, production-grade lifecycle with security, performance, observability, and deprecation coverage, but extending it with custom skills risks conflicting with its routing logic.

Osmani's own comparison doc is explicit about this limit: "What does not work is running two of them as your active router at the same time. Stacked meta-skills fight over command names, compete on routing logic, and pull in different TDD philosophies."

A second dimension separates them: autonomy versus control. Superpowers optimizes for hands-off execution. You brainstorm, plan, then walk away while subagents implement and review. Agent Skills puts a human checkpoint at every phase by default. Pocock optimizes for requirements interrogation before any code is written.

When To Use What

Based on the repos, the design docs, and community discussion:

Superpowers fits when:

The problem is ambiguous and needs architectural reasoning before coding
You want to hand off a large task and come back to a reviewed result
You value composability and want to cherry-pick individual skills into your workflow
The work is exploratory, with no established pattern to follow

Agent Skills fits when:

A feature needs to go from spec through security review to deployment
You want a complete lifecycle workflow with human checkpoints at each phase
You are standardizing agent usage across a team and need shared vocabulary
You care about breadth: security, performance, observability, CI/CD, deprecation
You want evals that verify the skills themselves work correctly

Matt Pocock's skills fit when:

Your primary bottleneck is requirements clarity, not execution speed
You want a lightweight, composable toolkit that does not impose a process
You want the sharpest requirements interrogation loop of the three
You prefer skills that are easy to read, modify, and make your own

Use none of them when:

The task is small and well-defined. Plain prompting works fine, and process overhead hurts more than it helps.

All three are MIT licensed and free. All three install into Claude Code, Cursor, Codex, and most major agent tools. You can try one for a week, switch, or cherry-pick individual skills across all three (as long as you pick one as your primary router).

What Nobody Has Tested Yet

Every comparison I found, formal and informal, runs framework A against framework B on the same task and measures the difference. Nobody has established the baseline: does any framework produce better results than running the same model with no framework at all?

This matters because skill frameworks add token overhead. They inject instructions, routing logic, and process steps into the context window. On simple tasks, that overhead could degrade results. On complex tasks, it could improve them. Without a baseline, you cannot tell.

A fair test would be straightforward: same model, same prompt, same repository, five runs with no framework, five runs with each framework, then compare code quality, test coverage, and bug count. Until someone runs that, the debate over which framework is best is missing the more fundamental question.

Sources: