A comparative map of the toolkits people have built to make AI coding agents follow a software development lifecycle — and a synthesis of what they all turn out to agree on.
A wave of open-source “agent frameworks” appeared through 2026: GSD, Spec Kit, BMAD, OpenSpec, Superpowers, gstack, Compound Engineering, Agent OS, pstack, Builder Skills and others. Each ships a bundle of slash-commands, skills, and sub-agents that walk a coding agent from a vague idea to merged code. They use different vocabulary, disagree about ceremony, and are mostly documented only by their own READMEs — so it is genuinely hard to tell whether two of them are doing the same thing under different names.
This wiki reads them side by side. Every framework is decomposed into its individual capabilities, each capability is tagged with the lifecycle stage it performs and the techniques it applies, and matching capabilities across frameworks are linked to one another. What emerges from those links — rather than from anyone’s opinion — is a canonical eight-stage lifecycle and a set of recurring patterns that most frameworks independently converged on.
It currently covers 14 frameworks, 422 capabilities, 41 artifacts, 39 patterns, 4 agent harnesses, 5 execution runtimes, 2 state stores, and 1 capability registry.
How it is organised
Five layers, from where the agent’s instructions came from, through what it does, down to what is left when it stops:
- Process layer — a framework ships capabilities (commands, skills, sub-agents). Each capability performs one canonical sdlc-stage, produces artifacts, and applies patterns.
- Harness layer — the agent program itself (Claude Code, Droid, opencode, pi): the loop that loads those skills and executes tool calls. Frameworks run on a harness.
- Runtime layer — the substrate deciding where and how agents run: sandboxes, parallelism, unattended autonomy, branch→PR. Runtimes spawn harnesses.
- Store layer — the durable work graph and memory that outlives any single run, so a session that ends or crashes does not take the work with it. The framework, harness and runtime layers are compute and are gone when the run ends; this is the one that survives.
- Registry layer — the versioned index capabilities are discovered in, scanned, scored, evaluated and installed from, before any run begins. Where a store holds what a run produced, a registry holds what a run was provisioned from.
Two page types are derived rather than authored. Stage pages are synthesised purely from the capabilities that link to them — they are evidence summaries, not opinions, and get re-derived on every ingest so the stage names stay neutral rather than borrowing one framework’s branding. Topic pages are the opposite: hand-written essays that cut across everything else.
The full schema — node types, relationship edges, naming rules, and the discipline for when a new abstraction is allowed to exist — is in CONVENTIONS.
Ways to use it
Choosing a framework. Start at the framework catalogue. Each entry states the framework’s shape, its signature idea, which stages it covers and which it skips, and how heavy it is. Useful contrasts: Spec Kit (gated, maximalist, the reference spec-driven implementation) vs nano-spec (four tiny files) vs Superpowers (a complete methodology from 14 auto-triggering skills) vs Agent OS (deliberately owns only the front of the lifecycle) vs pstack (ships no spec step at all and puts every gram of its rigor into verification and review). If none of them fit because what you actually lack is durable state rather than a methodology, the answer is a layer down: see the store layer.
Borrowing one good idea instead of adopting a whole framework. Most teams don’t want another methodology; they want the two or three moves that actually work. Browse the capability catalogue or a stage page, find the cluster of frameworks solving the same problem, and take the best-shaped version. Cross-framework counterparts are linked on every page.
Deciding how much process you actually want. The collection now spans the full range, and the poles are worth reading against each other. Spec Kit and OpenSpec front-load a written contract and gate everything against it; pstack argues the opposite case in its own README — “i don’t believe in planning, the best spec is code” — and instead spends its rigor downstream on graded evidence, multi-model review, and generated verification harnesses. Neither is the consensus; the disagreement about where in the lifecycle rigor belongs is one of the more useful things visible only when these tools are read side by side.
Finding the high-confidence practices. The pattern pages record how many independent frameworks converged on each technique. A pattern shared by eight frameworks that never talked to each other is a much stronger signal than any single project’s README — that is the main thing this wiki produces that reading the sources individually cannot.
Designing your own skill library. The eight stage pages are a checklist of what a complete lifecycle has to cover, with every known implementation of each stage listed underneath. Use them to find your gaps — most homegrown setups are missing review as distinct from validate, or learn entirely.
Improving the repo the agent works in. Before adopting any process, check whether your codebase can support one. Agent readiness covers the two public scoring rubrics for exactly that; the sibling harness engineering covers how to steer agents toward your conventions; and the compounding loop covers how those controls get better over time — what a toolchain can read about work that already happened, and what it writes so the next run starts ahead. These three topics are the most directly actionable pages here.
Rolling this out across an organization. The community frameworks assume one motivated engineer; the AI-native SDLC covers the org-level view — Anthropic’s own enterprise playbook (committed artifact chain, advisory-skill/deterministic-hook controls, governance enforced as the agent acts) read against the wiki’s stages and patterns, with the convergences and the one instrument nobody else ships noted.
Letting agents act without a human in the loop. Once work arrives unattended (a user report, a Sentry error, a queue of PRs), the hard question stops being can the agent fix it and becomes which of its consequences is it allowed to cause. The Factory in Builder Skills is the clearest answer here. It splits authority into ten independently authorized actions (fix, reply, close, review, approve, publish, merge, deploy, recover, notify), never lets one imply another, ties evidence to the exact PR head, and keeps a read-only queue of whatever still needs a person (pattern-action-gating). Read it against gh-aw, which enforces the same decomposition in CI job structure instead of instructions, and against the software-factory topic for where each approach sits.
Managing skills at organizational scale. Every framework here encourages writing more skills, and none of them manages the corpus that results — which is why a commercial layer has grown to do it. The registry layer covers capability distribution as a supply chain: versioning and rollback, security scanning of instructions (pattern-supply-chain-scanning), measuring whether a skill actually changes agent behavior (pattern-capability-evals), org-wide inventory, RBAC and install policy. Read it if your problem is no longer which skills should we write but which of the two hundred we have are any good, and who is allowed to install them.
Picking the substrate. The harness matrix compares agent programs on sub-agents, MCP, hooks, permissions, and model access; the runtime matrix compares isolation, parallelism, autonomy, and steering; the store matrix compares the two work-tracking substrates on storage, merge, memory, and ephemerality. All three are decisions people usually make by default rather than deliberately. For the execution layer’s general architecture — what a software factory is made of, the four design axes, and which configuration to start with — read the topic page before the matrix.
Making long-horizon work survive. Everyone hits the same wall on the second week: markdown plans rot, TODO comments scatter, and a crashed agent takes its context with it. The store layer is the two documented answers to that — beads and seeds — compared on storage, merge behaviour, memory, ephemerality, and how much methodology a tracker should carry. Both agree on the core move (a dependency graph whose unblocked frontier is the work queue) and disagree on almost everything else, which makes the pair unusually informative.
Getting oriented in the field. Read CONVENTIONS for the vocabulary, then any two framework pages. The visual artifact index shows how the documents these tools produce flow into one another across a whole lifecycle.
Provenance
Every article is compiled from captured primary sources — each framework’s own documentation and source, archived unmodified before compilation. Pages cite what they were built from and when. The change history, including the reasoning behind every schema decision and stage rename, is in the log.
Nothing here is a benchmark: the wiki records what these tools claim and contain, not measured outcomes. Star counts and version numbers are as-of their capture date.
The full catalogue
Every article in the wiki, one section per namespace, is listed on a single page: Catalogue — framework · capability · sdlc-stage · artifact · pattern · harness · runtime · store · registry · topic.