AI Workflow Frameworks for Software Development: A Layered Comparison

Disclaimer

This article synthesizes research produced with the help of multiple AI systems. Its purpose is to provide orientation in a fast-moving landscape of emerging tools by offering a practical taxonomy.

It should not be treated as a decision document. Use it as a starting point for tool-specific deep dives and validation against primary sources before making adoption decisions.

What's in the article

• Layers of AI Workflow Tooling - Explains the layering model used in the article and why different kinds of AI tooling should not be compared as if they do the same job.
• Framework Landscape - Walks through the main frameworks and supporting layers so you can see what each one actually owns.
• Relationship Map - Summarizes which tools are clean substitutes, which ones compose well, and which combinations create overlap.
• How the Core Frameworks Run - Shows how the core options structure day-to-day work and where their operating discipline comes from.
• Operational Comparison - Looks at practical tradeoffs such as adoption speed, portability, brownfield fit, and common failure modes.
• Adjacent Layers - Covers nearby tools that influence the stack without usually becoming the main workflow framework.
• Quick Installs - Gives a fast reference for getting the most relevant tools installed and ready to try.

Layers of AI Workflow Tooling

There is no single "AI coding workflow" anymore: current tools split across methodology frameworks, task and control layers, skills systems, host-native agent capabilities, and integrated products. This comparison focuses on the layers and frameworks that matter most for solo developers and small teams, with emphasis on where they truly compete and where they are better combined.

The fastest way to make sense of this space is to separate tools by what part of the delivery loop they actually change.

Framework Landscape

Once the layers are separated, the real substitute set becomes much smaller.

Main Workflow Owners and Near-Core Control Planes

BMAD Method

• Primary layer: Workflow framework
• Capabilities: role-specialized planning, architecture and story tracks, explicit phase handoffs
• Persistent artifacts: _bmad/, _bmad-output/, project context, stories
• Control surface: method phases, role prompts, and artifact checkpoints

GSD

• Primary layer: Workflow framework
• Capabilities: compact command-driven flow, durable repo-local state, phased execution with project memory
• Persistent artifacts: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, .planning/
• Control surface: phase commands plus repo-backed state files

GSD-2

• Primary layer: Coordination/runtime with workflow semantics
• Capabilities: session management, budget and slice control, orchestration around execution
• Persistent artifacts: .gsd/ state, sessions, budgets, migration tooling
• Control surface: runtime sessions, orchestration controls, and budget policies

Superpowers

• Primary layer: Workflow framework
• Capabilities: plan-before-code behavior, enforced review loops, subagent and TDD discipline
• Persistent artifacts: skill files, plans, worktrees, review flow
• Control surface: host-loaded skills, required workflows, and review gates

Spec Kit

• Primary layer: Workflow framework
• Capabilities: spec-first planning, constitution/spec/plan/tasks scaffolding, repo-first portability
• Persistent artifacts: .specify/, specs/..., templates, scripts
• Control surface: generated artifacts and scripts rather than a heavy runtime

TaskMaster

• Primary layer: Coordination layer
• Capabilities: PRD-to-task decomposition, dependency tracking, resumable execution ordering
• Persistent artifacts: .taskmaster/, tasks.json, MCP/CLI state
• Control surface: task graph, MCP tools, and CLI commands

Kiro

• Primary layer: Integrated environment
• Capabilities: managed spec flow, built-in agents and hooks, bundled runtime and UI
• Persistent artifacts: .kiro/, agent configs, product-managed execution state
• Control surface: Kiro IDE, CLI, runtime, and product-defined workflow surface

Composable Capability Layers

Anthropic Skills

• Primary layer: Skills substrate
• Capabilities: reusable micro-workflows, domain packaging, progressive disclosure of instructions, scripts, and resources
• Persistent artifacts: skill folders with SKILL.md, scripts, resources
• Control surface: skill invocation and dynamic loading inside Claude-centered hosts

Claude Code subagents

• Primary layer: Host-native agent capability layer
• Capabilities: separate contexts, tool-scoped specialists, built-in delegation inside the host runtime
• Persistent artifacts: .claude/agents/, user-level agent definitions, /agents
• Control surface: native subagent runtime and host delegation commands

Codex

• Primary layer: Host-native agent capability layer
• Capabilities: parallel agents, cloud tasks, worktree-based isolation, app, IDE, and cloud task surfaces
• Persistent artifacts: per-task cloud environments, worktrees, task surfaces
• Control surface: native parallel-agent surface and task orchestration in Codex

Adjacent Governance, Artifact, and Overlay Layers

OpenSpec

• Primary layer: Workflow framework
• Capabilities: change-scoped specs, archival flow, artifact-first change management
• Persistent artifacts: openspec/changes/<change-id>/, tasks.md, archive flow
• Control surface: change folders and task artifacts

Continue

• Primary layer: Repo governance layer
• Capabilities: AI review rules, policy checks, in-repo quality automation
• Persistent artifacts: .continue/checks/
• Control surface: configured review checks layered on top of an existing workflow

GitHub Agentic Workflows

• Primary layer: Repo automation layer
• Capabilities: recurring AI jobs, repo triage, GitHub-native automation
• Persistent artifacts: workflow markdown plus compiled actions flow
• Control surface: GitHub Actions and workflow definitions

SuperClaude

• Primary layer: Behavior overlay
• Capabilities: command shortcuts, personas, and host-specific behavior shaping
• Persistent artifacts: rules, commands, persona config
• Control surface: overlay rules inside Claude-centered hosts

wshobson/agents

• Primary layer: Skills marketplace
• Capabilities: capability catalog, installable agents, skills, and tool bundles
• Persistent artifacts: plugin bundles with agents, skills, tools
• Control surface: marketplace and plugin loading rather than a single workflow method

The main substitute set is still BMAD Method, GSD, Superpowers, Spec Kit, and Kiro. GSD-2 is the boundary case because it can become the runtime around which work is organized, even when it is not the visible methodology.

TaskMaster, Anthropic Skills, Claude Code subagents, and Codex are better understood as composable layers. They can accelerate or harden a primary workflow, but they do not replace the decision about where specs, tasks, checkpoints, and review rules live.

The closest internal boundary is the artifact-first branch. Spec Kit and OpenSpec both externalize intent into repo-readable artifacts, but OpenSpec is explicitly per-change and archival, while Spec Kit behaves more like a reusable baseline for spec-driven work across the repository.

Relationship Map

These tools can be used in combination, but not all combinations are clean. In most practical stacks, one tool owns the main delivery loop and everything else stays subordinate.

The matrix below is a compatibility shortcut. It helps separate additive combinations from combinations that create a second system of record for specs, tasks, or execution control.

Legend: S substitute, C complement, O overlap, M mixed.

Abbreviations: SP Superpowers, SK Spec Kit, TM TaskMaster.

This map intentionally excludes Claude Code subagents and Codex. They are host-native delegation features, not independent workflow methods, so they amplify several rows here without becoming substitute rows of their own.

Four relationships matter most. First, BMAD, GSD, Superpowers, Spec Kit, and Kiro are still the main-loop substitutes. Second, TaskMaster is complementary only when it becomes the single task system of record; otherwise it creates a second task truth. Third, Anthropic Skills are usually additive because they package repeatable capabilities instead of defining a lifecycle. Fourth, GSD-2 remains mixed: it can sit under another method, but overlap has to be managed deliberately because sessions, budgets, and orchestration can start competing with another control plane.

How the Core Frameworks Run

This table captures the first selection question: how each option actually structures work and where its process discipline lives.

The biggest divide is where discipline lives. BMAD and Superpowers put it in the method, GSD puts it in state and command flow, Spec Kit puts it in artifacts, Kiro puts it in the product surface, and TaskMaster or GSD-2 put it in control planes. That is why the main choice is usually less about features than about what you want to become the system of record.

Operational Comparison

This section covers the operational side: time to first useful result, working-state portability, brownfield behavior, layering fit, and the main failure mode to watch.

BMAD Method

• Getting to a first credible result: Slower than lighter methods because the payoff appears after setup and artifact creation.
• Working state and exit cost: Low product lock-in; most state is repo-backed and inspectable.
• Brownfield behavior: Strong when an existing system needs deliberate mapping, but heavy for small opportunistic changes.
• Layering behavior: Works with Skills and sometimes TaskMaster, but multiple planning spines get noisy quickly.
• Main caution: Ceremony can dominate small or routine work.

GSD

• Getting to a first credible result: Fast among open methods because the entry surface is compact and state stays near the repo.
• Working state and exit cost: Moderate host or runtime dependence, but durable artifacts keep exit cost manageable.
• Brownfield behavior: Good when codebase mapping and phased work matter in an existing repo.
• Layering behavior: Can take Skills or TaskMaster, but only if they do not compete with GSD's own state and task flow.
• Main caution: It relies on the host or runtime actually respecting the method cleanly.

GSD-2

• Getting to a first credible result: Harder than GSD because runtime concepts must be learned before the payoff is clear.
• Working state and exit cost: Some state is portable, but the main value lives in runtime behavior and orchestration controls.
• Brownfield behavior: Good when observability and budget control matter on an existing repo.
• Layering behavior: Most useful as the execution control plane; overlap rises quickly if another runtime also owns tasks or budgets.
• Main caution: A fast-moving runtime surface can outpace team habits.

Superpowers

• Getting to a first credible result: Reasonably quick on supported hosts, but the benefit appears only after accepting its guardrails.
• Working state and exit cost: Files are readable, but practical portability depends on hosts that honor the skill behavior cleanly.
• Brownfield behavior: Works in brownfield repos, though its main strength is execution discipline rather than legacy-system mapping.
• Layering behavior: Best as the primary method; stacking another strong methodology usually duplicates review and task rules.
• Main caution: Strictness is a feature if you want it and friction if you do not.

Spec Kit

• Getting to a first credible result: Fast to first useful result because the artifact model is easy to read and adopt incrementally.
• Working state and exit cost: Lowest exit cost in the set; the core value lives in plain repo artifacts.
• Brownfield behavior: Good in brownfield if the team will maintain the artifacts consistently.
• Layering behavior: Composes cleanly with Skills and sometimes TaskMaster because it leaves room above and below the artifact layer.
• Main caution: Enforcement is social; weak habits still produce weak results.

TaskMaster

• Getting to a first credible result: Fast if the main pain is coordination rather than methodology.
• Working state and exit cost: Low-to-moderate lock-in; task state is inspectable, but frameworks that already own tasks make it redundant.
• Brownfield behavior: Easy to add to existing repos because it does not require replacing the main editor or method.
• Layering behavior: Useful only when it is the clear task system of record.
• Main caution: Blind stacking creates a second task truth.

Kiro

• Getting to a first credible result: Fastest path to a complete environment because setup, agents, and workflow live together.
• Working state and exit cost: Highest exit cost; some state is file-backed, but the convenience lives in the managed product.
• Brownfield behavior: Good for teams willing to operate inside Kiro's surface.
• Layering behavior: Least cleanly composable with other full methods because specs, tasks, hooks, and runtime already ship together.
• Main caution: Convenience and lock-in rise together.

Anthropic Skills

• Getting to a first credible result: Not a first-run workflow by itself; value appears when you already know what capabilities you want to package.
• Working state and exit cost: Skill folders are portable in form, but practical gravity is still Claude-centered today.
• Brownfield behavior: Additive in greenfield or brownfield because it packages repeatable procedures rather than repo history.
• Layering behavior: Designed to compose with a primary workflow or host.
• Main caution: Not a replacement for a methodology or control plane.

The operational split is mostly about where working state lives and how much of the stack a tool tries to own. BMAD, GSD, Superpowers, Spec Kit, and Kiro differ less in feature count than in what they ask you to trust: the method, the repo artifacts, the runtime, or the product surface.

GSD-2 and TaskMaster move the center of gravity toward control planes. Anthropic Skills belongs in the comparison because it changes composability and repeatability, but it should not be read as an alternative to BMAD, GSD, Spec Kit, or Kiro.

Adjacent Layers

These tools stay adjacent because they sharpen a boundary in the stack without becoming the main workflow choice in most cases.

Most of the selection logic reduces to three questions: where you want discipline to live, whether you want repo-readable artifacts or a managed surface to hold the working state, and whether you need an additive control layer at all. The safest stacks stay narrow: one primary workflow owner, plus at most one clearly subordinate layer such as TaskMaster, Skills, Claude Code subagents, or Codex's native agent surface.

Quick Installs

Setup BMAD Method

Install docs: Getting Started with BMad

npx bmad-method install

Setup GSD

Install docs: GSD README

npx get-shit-done-cc@latest

Setup GSD-2

Install docs: GSD-2 Getting Started

npm install -g gsd-pi

Setup Superpowers

Install docs: Superpowers README Quick path: install it through your host's plugin flow. Examples from the README include /plugin install superpowers@claude-plugins-official in Claude, /add-plugin superpowers in Cursor, or manual host-specific install instructions for Codex and OpenCode.

Setup Spec Kit

Install docs: Spec Kit Installation Guide

Prerequisites: installed uv, Python 3.11+, and Git

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

Setup OpenSpec

Install docs: OpenSpec homepage / get started

Setup TaskMaster

Install docs: TaskMaster installation

For Cursor, Windsurf, or VS Code, use the MCP config shown in the install guide and add your model API keys. The fastest Claude Code setup:

claude mcp add taskmaster-ai -- npx -y task-master-ai