Swarm review

Skill AnmarHani/SwarmVault/skills/swarm-review

A shared knowledge vault + full software-engineering workflow for AI coding agents — run Claude Code and Codex in parallel with one memory, one plan.

Install

npx -y skills add AnmarHani/SwarmVault --skill swarm-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.0 KB, 645 tokens by cl100k_base, as published. Nobody here has run it

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

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?
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.
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.
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.