# Squad Review

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

- Skill: `nicknisi/squad-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add nicknisi/squad-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nicknisi/squad-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: nicknisi (https://skillmd.com/u/nicknisi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nicknisi/squad-review

---


# 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:

```bash
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.