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