Coding Agents Workflow Playbooks
This post is a summary of a ChatGPT conversation where I was researching these coding-agent workflow playbooks.
Coding Agent Workflow Frameworks: A Taxonomy of Agentic Software Engineering
Coding agents are increasingly capable of writing code. The harder problem is no longer simply getting an LLM to produce a function or modify a file. It is getting an agent to behave like a competent software engineer over the lifetime of a change.
Before implementation, it may need to inspect an unfamiliar codebase, clarify requirements, research alternatives, and produce a design. During implementation, it needs to make controlled changes, test them, and react to failures. Afterwards, it needs to review the result against the original requirements, identify unnecessary complexity, and provide evidence that the work is actually complete.
A raw coding agent does not necessarily do these things consistently. Given a feature request, its natural tendency is often to start editing code immediately.
This has produced a new category of tooling that can be described as coding-agent workflow frameworks, or more broadly, agentic software-engineering playbooks.
These systems encode opinions about how software engineering should be performed around an AI coding agent. Depending on the framework, those opinions may be expressed as reusable skills, explicit specifications, specialized agent roles, persistent artifacts, or orchestrated workflows.
They are therefore not simply collections of prompts, nor are they just mechanisms for spawning subagents. They attempt to encode some combination of engineering process, organizational structure, and project memory around the underlying model.
This article compares several prominent approaches and develops a taxonomy for understanding how they differ.
The frameworks
The projects considered here cover a deliberately broad range of approaches.
Matt Pocock’s Skills
Matt Pocock’s Skills are deliberately small, editable, composable engineering procedures. The project explicitly positions itself against systems that “own the process”: the developer retains control and selectively gives the agent better procedures for tasks such as investigation, planning, debugging, and review.
Addy Osmani’s Agent Skills
Addy Osmani’s Agent Skills take the same basic skill primitive further toward a complete engineering lifecycle. Skills encode step-by-step workflows, quality gates, verification requirements, and exit criteria, organized around phases such as defining, planning, building, verifying, reviewing, and shipping.
Superpowers
Superpowers describes itself as a complete software-development methodology implemented using composable skills. Rather than waiting for the developer to invoke good practices manually, it attempts to make practices such as requirements clarification, design, planning, testing, and review part of the default workflow.
Spec Kit
GitHub Spec Kit is centered on spec-driven development. Its default process is Spec → Plan → Tasks → Implement, with each phase producing Markdown artifacts that become structured context for subsequent phases. Modern Spec Kit is also extensible beyond that default workflow.
OpenSpec
OpenSpec is another spec-driven approach, but intentionally lighter. Its central argument is that requirements buried in conversation history are unstable; explicit specifications establish reviewable intent before implementation begins.
GSD
GSD — Get Shit Done combines spec-driven development with context engineering and multi-agent orchestration. Its explicit target is context rot: degradation in agent performance as a session accumulates increasingly large and noisy context. The original repository has since moved active development to Open GSD.
BMAD
BMAD Method models software development as a structured collaboration between specialized agents and workflows. It is closer to an AI-native software organization than to a simple prompt or skill library, with agents representing responsibilities associated with analysis, product, architecture, development, testing, and related disciplines.
wshobson/agents
wshobson/agents takes a specialist-agent approach: instead of defining a single universal software engineer, it provides a large ecosystem of domain-specific agents, skills, and orchestration patterns that can be composed into different engineering teams.
pi-subagents
pi-subagents is both a mechanism for delegating work to Pi child agents and an opinionated set of agent roles and orchestration patterns. It supports activities such as scouting, implementation, review, parallel audits, second opinions, and background work. Its documentation explicitly encourages patterns such as running independent reviewers for correctness, testing, and unnecessary complexity.
Popularity
GitHub stars are an imperfect measure of adoption or technical quality, but they provide a useful indication of the size of the community around each approach.
The ecosystem is moving unusually quickly, so these figures should be treated as approximate snapshots rather than durable rankings.
| Project | Approx. GitHub stars | Primary emphasis |
|---|---|---|
| Superpowers | ~270k | Enforced engineering methodology |
| Matt Pocock Skills | ~196k | Composable engineering procedures |
| Spec Kit | ~121k | Spec-driven development |
| Addy Osmani Agent Skills | ~92k | Structured SDLC skills |
| OpenSpec | tens of thousands | Lightweight spec-driven development |
| GSD | ~65k legacy repository | Context engineering and orchestration |
| BMAD Method | ~48k | Role-based software organization |
| wshobson/agents | tens of thousands | Specialist-agent ecosystem |
| pi-subagents | ~3k | Delegation and cognitive-role separation |
The exact ordering is less interesting than the diversity. Projects with substantial adoption are converging on very different answers to the same underlying question:
What structure should surround a coding model so that it performs reliable software engineering rather than merely generating code?
Five schools of thought
The frameworks are easier to understand when grouped by the primary problem they are trying to solve.
These categories are not mutually exclusive. Mature frameworks frequently borrow ideas from several of them. They describe the framework’s center of gravity.
1. Skills as engineering knowledge
Examples: Matt Pocock, Addy Osmani
The first school starts from a relatively simple assumption:
The coding agent is already capable. The problem is that it does not consistently follow good engineering discipline.
The solution is to encode expert procedures as reusable skills.
A skill might teach the agent how to:
- interrogate vague requirements;
- investigate an unfamiliar codebase;
- construct an implementation plan;
- practice test-driven development;
- debug systematically;
- review a change;
- verify completion.
The conceptual model is:
requirements
↓
investigation
↓
planning
↓
implementation
↓
testing
↓
review
The important point is that these stages do not necessarily constitute a mandatory framework-owned state machine. They can remain composable capabilities.
Matt Pocock’s approach sits toward the minimalist end of this school. His repository explicitly argues for skills that are small, adaptable, and composable rather than frameworks that take control of the development process.
Addy Osmani uses the same basic primitive but applies more lifecycle structure:
DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP
His skills contain actionable steps, verification requirements, quality gates, and explicit exit criteria.
The main question this school asks is:
How should a competent software engineer perform this task?
Its primary component is the procedure.
2. Methodology enforced through skills
Example: Superpowers
Superpowers starts with the same idea—engineering knowledge can be encoded as skills—but reaches a more prescriptive conclusion:
Do not rely on the agent to decide whether good engineering process is necessary. Make the process itself the default.
The distinction is important.
A library might provide a TDD skill that the agent can use. A methodology can instead make TDD an expected part of implementation.
Similarly, rather than offering planning as an optional capability, the methodology can establish a sequence such as:
clarify intent
↓
design
↓
plan
↓
implementation
↓
testing
↓
review
↓
verification
Superpowers describes itself explicitly as a complete software-development methodology built on composable skills.
The main question becomes:
How do we make good engineering behavior systematic rather than optional?
Its defining components are procedures plus orchestration.
3. Specifications as the control plane
Examples: Spec Kit, OpenSpec
The spec-driven school identifies a different primary failure mode:
Project intent stored in chat history is a poor source of truth.
Requirements become diluted as conversations grow. Decisions made earlier may disappear from the active context. Implementation can drift away from what the user actually requested.
The answer is to externalize intent into durable artifacts.
A simplified Spec Kit flow looks like:
SPEC
│
▼
PLAN
│
▼
TASKS
│
▼
IMPLEMENT
Each stage produces an artifact consumed by later stages. Spec Kit’s documentation explicitly describes these Markdown artifacts as structured context for the coding agent.
This changes the relationship between intent and code:
Conventional conversational agent
prompt
↓
code
Spec-driven development
intent
↓
specification
↓
implementation plan
↓
tasks
↓
code
OpenSpec adopts the same fundamental principle but emphasizes a lighter workflow. Its goal is to establish agreed, reviewable behavior before implementation without necessarily imposing a large process framework.
The main question this school asks is:
What durable representation of intent should constrain implementation?
Its defining component is the artifact.
4. Context engineering as the architecture
Example: GSD
GSD focuses on another limitation: the context window itself.
Long-running agent sessions accumulate requirements, source code, tool output, failed approaches, plans, logs, and incidental conversation. Eventually the context becomes both large and noisy.
GSD calls the resulting degradation context rot and explicitly positions context engineering as part of its solution.
Instead of treating one conversation as the entire engineering environment, work can be distributed across fresh contexts while durable state connects them.
Conceptually:
ORCHESTRATOR
│
persistent state
│
┌─────────────┼─────────────┐
▼ ▼ ▼
research planning execution
context context context
│ │ │
└─────────────┼─────────────┘
▼
verification
This changes the unit of architecture.
The system is no longer simply:
prompt → agent → tools
It becomes:
workflow
+
context topology
+
persistent artifacts
+
specialized executions
+
verification
The main question this school asks is:
How should information and work be distributed so that agents maintain useful context throughout a large engineering task?
Its defining components are orchestration, artifacts, and context boundaries.
5. Software organization simulated as agents
Examples: BMAD, wshobson/agents, pi-subagents
The fifth school makes separation of responsibility itself part of the architecture.
Instead of asking one agent to understand, design, implement, and review its own solution, different agents receive different responsibilities and contexts.
The simplest form is:
ORCHESTRATOR
│
┌───────────┼───────────┐
▼ ▼ ▼
SCOUT WORKER REVIEWER
│ │ │
understand implement criticize
The key idea is not merely parallelism. It is cognitive separation.
A worker that just implemented a design carries the reasoning and assumptions that produced it. Asking that same context to review the implementation means asking it to challenge its own assumptions.
A fresh reviewer sees a different problem:
requirements
+
actual code
+
tests
↓
independent review
pi-subagents makes this especially explicit through focused child agents and patterns such as parallel reviewers specializing in correctness, testing, or unnecessary complexity.
wshobson/agents generalizes the idea into a large catalog of specialists.
BMAD goes further still by modeling much of the software-development organization itself through specialized agents and structured workflows.
The main question this school asks is:
Who should perform each kind of reasoning, and which responsibilities should be isolated from one another?
Its defining component is the role.
The four building blocks
The five schools describe philosophies. At a lower level, however, most of these frameworks are assembled from the same four kinds of building blocks.
Procedures: how
Procedures encode how a particular engineering task should be performed.
Examples include:
systematic debugging
test-driven development
requirements interrogation
code review
codebase investigation
performance analysis
They contain steps, heuristics, constraints, quality criteria, and sometimes explicit evidence requirements.
Skills are the most common packaging mechanism for procedures.
Roles: who
Roles encode who should perform a type of reasoning.
Examples include:
scout
researcher
architect
implementer
reviewer
security auditor
oracle
A role can constrain tools, context, responsibilities, output format, and decision authority.
Its purpose is not merely to make the agent pretend to have a job title. A useful role creates a boundary around responsibility and information.
Artifacts: memory
Artifacts encode what survives between phases and contexts.
Examples include:
requirements.md
spec.md
architecture.md
plan.md
tasks.md
STATE.md
verification.md
They serve as durable interfaces between humans, agents, and phases of work.
This is particularly important in multi-agent systems:
Agent A
│
│ writes
▼
PLAN.md
│
│ reads
▼
Agent B
Agent B does not need Agent A’s complete conversation. The artifact is the contract.
Orchestration: when
Orchestration determines what happens next.
It connects procedures, roles, and artifacts into a workflow.
understand
↓
spec
↓
plan
↓
implement
↓
review
↓
fix
↓
verify
More sophisticated orchestration may include parallelism, gates, loops, retries, independent reviewers, or human approval.
These four primitives form a useful general model:
SOFTWARE ENGINEERING
│
┌─────────────────────┼─────────────────────┐
│ │ │
PROCEDURES ROLES ARTIFACTS
"how" "who" "memory"
│ │ │
│ │ │
skills agents specs
rules subagents plans
checks reviewers ADRs
TDD scouts state
│ │ │
└─────────────────────┼─────────────────────┘
│
ORCHESTRATION
"when"
│
workflow / methodology
Different frameworks emphasize different primitives:
procedures roles artifacts orchestration
Matt Pocock █████████ ██ ██ ███
Addy Osmani █████████ ██ ███ ██████
Superpowers █████████ ███████ █████ █████████
OpenSpec ████ █ █████████ ██████
Spec Kit ██████ ██ █████████ █████████
GSD ██████ ████████ █████████ █████████
BMAD ███████ ██████████████████ █████████
pi-subagents ██████ █████████████ ██████
wshobson/agents ███████ ████████████ ███████
These values are qualitative, not measurements. Their purpose is to expose architectural emphasis.
For example, Matt Pocock’s approach is procedure-heavy but deliberately orchestration-light. OpenSpec is artifact-heavy without requiring an elaborate agent organization. pi-subagents is unusually role-heavy. GSD combines strong orchestration with persistent state and context separation.
That makes these approaches more complementary than their positioning sometimes suggests.
A three-dimensional taxonomy
The four primitives tell us what a framework is made of.
To compare the frameworks architecturally, three separate dimensions are more useful.
Dimension 1: Process control
The first question is:
Who decides what happens next?
developer-controlled framework-controlled
◀───────────────────────────────────────────────────────────────▶
choose skills as needed mandatory/expected stages,
gates and transitions
At the left, the framework provides capabilities while the developer or agent decides when to use them.
At the right, the framework increasingly defines the engineering process itself.
A rough spectrum is:
PROCESS CONTROL →
Matt ─── Addy ─── pi-subagents ─── Superpowers ─── Spec Kit ─── BMAD
│ │
toolbox methodology
The exact ordering is debatable. The useful distinction is between providing engineering capabilities and owning the lifecycle.
Dimension 2: Cognitive separation
The second question is:
How much reasoning should happen inside one agent context?
At one extreme:
AGENT
│
├── understand
├── plan
├── implement
├── test
└── review its own work
At the other:
ORCHESTRATOR
│
┌───────────┼───────────┐
▼ ▼ ▼
SCOUT WORKER REVIEWER
│ │ │
understand implement criticize
The spectrum is:
single cognitive context separated/fresh contexts
◀──────────────────────────────────────────────────────────────────▶
This dimension captures one of the strongest ideas behind multi-agent engineering: independent contexts can produce genuinely different reasoning rather than simply additional tokens.
pi-subagents, GSD, BMAD, and specialist-agent systems sit strongly toward the right.
Spec-driven systems do not inherently require this. One agent can execute an artifact-driven workflow.
Dimension 3: State externalization
The third question is:
Where does project truth live?
At one extreme:
CHAT / CONTEXT
"We decided earlier..."
"Remember that constraint..."
"As discussed above..."
At the other:
REPOSITORY / STATE
requirements.md
spec.md
architecture.md
plan.md
tasks.md
STATE.md
verification.md
The spectrum is:
conversation durable artifacts
◀──────────────────────────────────────────────────────────▶
This dimension is independent of the previous two.
A system can have a highly prescribed workflow while still relying heavily on conversational state. It can also be artifact-heavy without using multiple agents.
Spec Kit and OpenSpec sit strongly toward the artifact side because externalizing intent is central to their design.
GSD also sits strongly there, but for an additional reason: artifacts allow fresh contexts to communicate without copying the entire history of previous agents.
Putting the three dimensions together
The frameworks can now be compared without forcing them onto a single good/bad or simple/advanced axis.
| Framework | Process control | Cognitive separation | State externalization |
|---|---|---|---|
| Matt Pocock | Low | Low–medium | Low |
| Addy Osmani | Medium | Low–medium | Medium |
| Superpowers | High | High | Medium–high |
| OpenSpec | Medium–high | Low | Very high |
| Spec Kit | Very high | Medium | Very high |
| GSD | Very high | Very high | Very high |
| BMAD | Very high | Very high | Very high |
| wshobson/agents | Medium | Very high | Medium |
| pi-subagents | Low–medium | Very high | Medium |
Again, these are qualitative positions, not scores.
The important point is that the dimensions are independent design choices.
For example:
Matt Pocock
↓
How should an engineer perform task X?
pi-subagents
↓
Which cognitive role should perform task X,
and should it receive a fresh context?
OpenSpec / Spec Kit
↓
What durable artifacts should define
and constrain task X?
GSD
↓
How should tasks, artifacts and fresh contexts
be orchestrated without context degradation?
BMAD
↓
How should the entire software-development
organization and lifecycle be represented?
This also explains why apparently competing frameworks can be complementary.
A system could use:
durable specification
│
▼
orchestrator
│
scout/research
│
▼
plan
│
independent critique
│
▼
worker subagent
+ engineering skills
+ TDD procedure
│
▼
code
│
┌───────────┼───────────┐
▼ ▼ ▼
correctness testing simplicity
reviewer reviewer reviewer
└───────────┼───────────┘
▼
fix
│
▼
verification
│
▼
evidence report
There is no fundamental reason the specification must come from the same framework as the TDD procedure, or that the reviewer role must come from the system that defines project state.
The ecosystem is gradually discovering separable architectural primitives.
The underlying coding model provides intelligence. Procedures tell it how to work. Roles determine who performs each kind of reasoning. Artifacts preserve intent and knowledge. Orchestration determines when those pieces execute.
The real design question is therefore no longer simply which coding agent is best?
It is increasingly:
What software-engineering system should we build around the coding agent?