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:

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.