Swarm Review

---
name: swarm-review
description: Milestone review sweep — a strong model audits everything since the last sweep against the spec: requirement fulfillment, standards, simplification, risk. Use when a milestone's tickets are done, before opening the next milestone, or when asked to review/audit/validate completed work.
---

# swarm-review — the milestone gate

Reviews against the **spec**, not just the code — that is the difference between this and
a linter. Expect a top-tier model; warn if the session runs less. Milestone cadence only
(token economy): not per-commit.

**Scope:** the milestone's diff (git log since last sweep), its tickets, and its FR specs.

## The four lenses, in order

1. **Fulfillment** (the one that matters most): every Must-FR of the milestone,
   individually — no sampling. Are the acceptance criteria actually met? Do the tests
   *assert the criteria* (not just execute the code)? Is the FR → ticket → commit → test
   chain intact?
2. **Standards:** naming, error handling (exceptions handled, not swallowed), comment
   discipline (light, constraint-stating), test quality (behavior asserted, not
   implementation), commit hygiene — audited against swarm-implement's
   `references/clean-code.md` where available, **including its dogma traps**: fragment soup,
   one-implementation abstractions, pattern theater, and SRP shrapnel are findings, not
   compliance. **End-user text** shipped in the
   milestone (UI strings, README, release notes, marketing) is audited against the project's
   `voice.md` and the audience firewall — load swarm-write for the criteria.
3. **Simplification:** duplicated logic to merge, needless abstraction to delete, blocks
   that could be simpler or generalized. If a fix is obvious and small, still ticket it —
   see the rule below.
4. **Risk:** input validation gaps, security smells, and a devil's-advocate pass — "what
   assumption, if wrong, hurts most?"

## Findings

One per issue, compact (machine lane): severity (`blocker/major/minor`), FR link,
`file:line` evidence, concrete suggested fix. Write the report to
`30 Plans/<P>/reviews/M<N>-sweep.md` (human-lane summary + machine-lane findings), then
**one ticket per accepted finding** — findings that stay chat messages die in scrollback.

**Never auto-fix.** Reporting and fixing in the same pass corrupts the review; fixes are
swarm-implement's job via the tickets.

## Closing the gate

- **Gated mode:** present the report; the user decides what's waived; milestone closes on
  their word.
- **Auto mode:** the sweep IS the gate — `blocker`/fulfillment findings must be fixed and
  re-swept before the next milestone opens; the user reads the report in the vault at
  their leisure. Minor findings may carry forward as open tickets.

Update flow-state either way (J1).

---
*Influences: Pocock's code-review (two-axis); Jeffallan's code-reviewer &
security-reviewer & the-fool; superpowers verification-before-completion; euxx
code-simplifier — see CREDITS.md.*