/squad-review

name: squad-review
description: >-
  Review the current branch with six specialist lenses (security, correctness,
  conventions, tests, architecture, duplication), then put every finding
  through an adversarial verifier that tries to refute it — so what reaches you
  has already survived a skeptic. Use when the user asks for a thorough,
  deep, or paranoid review, a review before merging or shipping, a "real"
  review, or wants to know what a review would catch that a quick pass misses.
  Costs 12 agents; for a fast single-pass read, use the built-in code-review
  skill instead.
argument-hint: Optional — what to review (defaults to the branch diff vs main)

Squad Review

Six lenses in parallel, each finding then attacked by a verifier that assumes it is wrong until proven otherwise. The verification is the point: an unverified fan-out produces six sections of plausible noise, and you stop reading it by the third review.

Run it

Resolve the script path, then hand it to the Workflow tool:

echo ${CLAUDE_PLUGIN_ROOT}/skills/squad-review/scripts/workflow.js

Workflow({
  scriptPath: "<the path printed above>",
  args: { scope: "<git command>", label: "<human description>" }
})

Pick the scope yourself

Read the git state and choose — do not open a menu:

• On a feature branch with commits → `git diff main...HEAD` (the normal case)
• On main, or a branch with only uncommitted work → `git diff HEAD`
• Untracked files present and relevant → name them in `label` so reviewers read

them in full; a diff won't show them

• Nothing to review → say so and stop, don't launch the workflow

Ask only when two scopes both have substantial content and you genuinely can't tell which one the user means. If the user named a scope, use it.

Report the result

`findings` are ranked and already verified. Present them grouped by severity, not by lens — the lens is metadata, not structure. Lead with blockers. Give each finding its file:line, what breaks, and the fix direction.

Three fields decide whether the review can be trusted, and all three must reach the user:

• **`refuted`** — say how many and why, in one line. That number is the evidence

verification happened. Hiding it makes this look like every other review.

• **`unverified`** — findings whose verifier never ruled on them. Report them

under a separate heading that says exactly that. They have _not_ survived a skeptic, so never merge them into the findings list.

• **`lenses_failed`** — non-empty means the review is incomplete. Name the lenses

that died. Never present a partial review as a clean bill of health.

Do not re-rank or soften what the verifiers confirmed, and do not write the report to a file unless asked.

Requirements

Needs Claude Code's Workflow tool. This skill also ships to Pi via the repo's `pi.skills` glob, where that tool does not exist — there it will not run, and that is the intended failure rather than a silent degradation to something weaker.