SDLC Agent-Skill Wiki

Stage: Review

8 min read

Canonical lifecycle stage: judge that the built software is good before it ships — a quality gate over the code and its design, distinct from confirming it works (stage-validate). Review asks is it good? — is it correct under scrutiny, secure, performant, simple, well-architected, on-brand — and produces assessments and fixes (review reports, security/perf audits, simplifications), not a pass/fail on runtime behaviour. It runs after the build and typically gates entry to stage-release.

Derived projection — evidence is the capabilities that implements: [[stage-review]].

New stage (split out of stage-validate on 2026-07-05). Long the strongest parked split candidate on stage-validate: validate = confirm the software works (functional: UAT, runtime/browser tests, spec-conformance); review = confirm it is good (quality gate). Addy Osmani was the first framework to treat these as two distinct phases (a Verify phase ∥ a Review phase). gstack cleared the ≥2-framework bar: its sprint runs a distinct Review phase (code gstack-review + cross-model gstack-codex + design/DX/security) held separate from a distinct Test phase (functional QA gstack-qa). Two frameworks with the clean Verify∥Review partition → promoted, exactly as stage-specify was split from stage-plan and stage-learn from stage-release. See Why a distinct stage. Superpowers (2026-07-17) is now a third framework with the partition — functional sp-verification-before-completion ∥ quality sp-requesting-code-review — further confirming the split.

Why a distinct stage, not a flavor of validate

stage-validate executes the software and observes: does the feature work, do the tests pass, does the build match the spec? Review never runs the feature to check behaviour — it reads the artifact and judges its quality: a reviewer finding a race condition that passes CI, a security auditor modelling an exploit, a performance engineer flagging a regression, a simplifier removing complexity, an architect checking module boundaries. The two are adjacent (both gate release) but categorically different: validate is empirical (run it, observe), review is evaluative (read it, judge). Three frameworks (GSD, OpenSpec, Spec Kit) ship a functional validator but no quality-review capability at all — the cleanest evidence that the two activities are separable.

Matt Pocock — Skills for Real Engineers:

Addy Osmani — Agent Skills (its Review phase — skills + the /ship persona fan-out):

BMAD:

Compound Engineering (loop steps 4–5, plus review sub-agents):

gstack (its Review sprint phase — distinct from its Test phase):

Superpowers (review as a dispatched fresh-context gate + the reception discipline):

pstack (the densest review roster relative to framework size, and the one that rejects the persona mechanism):

Tessl — a registry, not a framework, and the only non-process layer with a real presence in this stage (see how to weight it below):

builder-skills:

Cross-framework equivalents

The quality-review clusters span the six frameworks that ship a review capability:

Note GSD, OpenSpec, and Spec Kit ship no review capability — they validate functionally (gsd-verify-work, openspec-verify, speckit-converge) but do not treat quality review as a step. Their absence here is what makes review and stage-validate cleanly separable.

A note on the registry entries

Three of the capabilities above belong to tessl, which is a registry rather than a framework. They are listed because they genuinely perform this stage, but they should not be read as a framework’s stage coverage: a registry’s command surface is overwhelmingly off-stage by construction, and these are the product growing sideways into the lifecycle it was built to supply. The conventions call this out as the expected shape for the layer.

What they do add is a distinct posture. The framework-side review capabilities optimize one engineer’s rigor — pstack-blast-radius demands a safety fact be proven by running code, gstack-review reads like a staff engineer. The registry-side ones optimize an organization’s throughput: a risk verdict as an exit code, a judge budget with a hard ceiling, a review roster you pin like a dependency. Same stage, different scaling problem, and the contrast is the reason to keep them on the page.

See Also

Graph View

Backlinks