SDLC Stages

Index — the eight canonical stages, in execution order.

The eight canonical, framework-neutral lifecycle stages synthesized across the frameworks in this wiki. Each is a derived projection — its content comes from the capabilities that implements: it (see CONVENTIONS.md for the ontology). Listed below in the order they typically execute.

The lifecycle is a loop, not a line: the last stage (Learn) feeds its output back into the front (Align) so each iteration starts ahead of the last.

flowchart TD
    A([1 · Align]) --> S([2 · Specify])
    S --> P([3 · Plan])
    P --> I([4 · Implement])
    I --> V([5 · Validate])
    I --> R([6 · Review])
    V --> Rel([7 · Release])
    R --> Rel
    Rel --> L([8 · Learn])
    L -. grounds the next iteration .-> A

Framework × stage support matrix

How completely each framework covers the eight stages, derived from the implements: edges of its capabilities (rows ordered by lifecycle coverage, most complete first).

Legend: 🟢 native — a dedicated step (named phase or several capabilities) · 🟡 partial — one or two capabilities, not a distinct phase · 🔗 folded in — the activity happens inside an adjacent stage, no standalone step · ➖ none — no capability for this stage. The final Off-stage column is a count, not a support level: how many of the framework’s capabilities map to no lifecycle stage at all (enumerated in Off-stage capabilities below).

Off-stage capabilities

The 12 capabilities that map to no lifecycle stage — cross-cutting tooling that runs around the pipeline rather than advancing it. Grouped by kind:

• Routing / dispatch & bootstrap — the one near-universal off-stage capability (four frameworks, all equivalent_to-linked): addy-using-agent-skills, mp-ask-matt, gstack-router, sp-using-superpowers (“which skill fits?” meta-skills; the Superpowers one doubles as the mandatory-skill-invocation bootstrap).

• Session & context continuity — mp-handoff (compact a conversation into a handoff doc so a fresh session resumes without re-deriving context). (gstack’s gstack-context-save / gstack-context-restore do the same job but the wiki files them under Implement.)

• Spec-pack state ops — nano-spec-status, nano-spec-update (report on / mutate an existing nano-spec pack rather than advancing a step).

• Publishing & diagrams — gstack-diagram (Diagram Maker), gstack-make-pdf (markdown → publication-quality PDF).

• Tooling & self-maintenance — gstack-benchmark-models (cross-model benchmark of gstack’s own skills), gstack-upgrade (self-updater), bm-favicon-creator (favicon asset generator).

• builder-skills (added 2026-09-26, 12 more, not folded into the count above): Factory supervision (builder-factory, builder-factory-human-digest, builder-factory-watchdog, builder-factory-recover); autonomy and cost (builder-plow-ahead, builder-efficient-fable, builder-efficient-frontier, builder-stay-within-limits, builder-quick-recap); and Agent-Native host surfaces (builder-an, builder-webmcp, builder-rewind). Half of the framework is off-stage, and most of that half is the supervision layer of an unattended factory: configuring policy, queueing human decisions, nudging stalled work, and resuming interrupted runs. That is a new kind of off-stage capability, with no router among them.

• matt-pocock-skills (v1.3.1, added 2026-10-11, 3 more, not folded into the count above): mp-wizard (generates a bash script for steps only a human can perform), mp-wait-what (a three-line corrective that re-pitches a message that didn’t land), and mp-writing-for-agents (the reference for writing skills and steering files). With mp-ask-matt and mp-handoff that makes 5. They are cross-cutting tools of a loose toolkit: a human-in-the-loop escape hatch, a communication repair, and a writing standard. In the same release MP’s Release and Learn cells moved from ➖ to 🟡 (mp-pr, mp-retro), so the toolkit now touches 7 of 8 stages (no Validate).

The pattern: the five frameworks that own the whole process (GSD, OpenSpec, Spec Kit, BMAD, Compound Engineering) keep everything on the lifecycle — zero off-stage capabilities. The toolkit / marketplace-style ones (gstack, Matt Pocock, nano-spec, BM Skills — and Addy/Superpowers with their routers) ship standalone utilities alongside the pipeline. gstack alone accounts for 5 of the 12, consistent with it being the largest, most “virtual-engineering-team” framework here.

^† OpenSpec’s Release is a spec-merge (archive), not a code deploy — gstack is the only framework here with a genuine deploy step. Folded (🔗) cases: GSD, Superpowers, and Compound Engineering capture the what inside Align/Plan rather than a separate spec; OpenSpec bundles design + task-decomposition into its propose (specify) step. BM Skills and nano-spec are deliberately point tools, not full-SDLC frameworks.

Stores on the stage map

The matrix above is framework × stage, and the store layer is deliberately not in it. A store holds durable work state; running around the lifecycle rather than advancing it is what it is for, so scoring one against eight stages would rank it low for succeeding at its job. Two stores nonetheless ship some genuine lifecycle work, listed here so the evidence stays visible without competing with framework rows:

The gap between the two rows is the layer’s own open argument, not a quality difference. Beads’ charter forbids carrying methodology — “the orchestration layer owns […] workflow semantics” — so its single on-stage capability is deliberate minimalism, and even that one is template instantiation rather than reasoning. Seeds bakes a planning methodology into the store so that the plan and the queue are one object. The rest of the contrast is in the store matrix.

What this means for the rosters: a Seeds: or Beads: group under stage-plan is store evidence, and it is weaker evidence for a stage than a framework’s — a store implements a stage as a side effect of holding state about it, where a framework implements it on purpose. Weight it accordingly during re-derivation; in particular, a candidate stage evidenced by two stores and no framework has not cleared the bar.

Notes on ordering

• Stages 5–6 (Validate ∥ Review) are sibling gates, not a strict sequence. Both run after Implement and both must pass before Release, but their order varies by framework — Addy runs Verify → Review, gstack runs Review → Test. They are listed 5 then 6 for a linear read; treat them as parallel quality gates.
• Stages 2–3 (Specify → Plan) were once one stage; stage-specify was split out once ≥2 frameworks treated authoring the spec as its own step. Some frameworks (e.g. OpenSpec) still fold planning into the specify step.
• Stage 8 (Learn) closes the loop. Its output — a solution corpus, a retrospective, an updated living spec — is read as grounding by Align, Plan, and Review at the start of the next iteration.
• Not every framework implements every stage (e.g. GSD/OpenSpec/Spec Kit ship no Review capability; Spec Kit ships no Release step). A stage page is only as strong as the capabilities that link into it.

See the global Knowledge Base Index for the full cross-namespace catalogue.