feat: multi-model consensus review for PR Review Squad

[PureWeen]

Each worker runs on Opus and dispatches parallel sub-agent reviews to Opus, Sonnet, and Codex. Findings require 2/3 model consensus to be included.

Changes

• .squad/agents/reviewer/charter.md — Full review charter: fetch diff → 3 parallel sub-agents (Opus, Sonnet, Codex) → consensus synthesis → ranked report
• .squad/team.md — Updated to describe multi-model workflow
• .squad/decisions.md — Consensus filter updated from 5 to 3 models

[PureWeen]

🔍 Squad Review — PR #443

PR: feat: multi-model consensus review for PR Review Squad
Size: +37/-3, 3 files (.squad/ markdown only — no production code)
Commit: 0df9abdc

---

Changes Reviewed

.squad/agents/reviewer/charter.md (new file, 34 lines)
Defines the multi-model review workflow: fetch diff → 3 parallel sub-agents (Opus, Sonnet, Codex) → 2/3 consensus filter → ranked report. Clear and actionable. Instructions correctly specify:

• gh pr diff <N> (never check out branch) ✅
• Consensus threshold: 2+ of 3 ✅
• No style/formatting feedback ✅
• Fallback if a model is unavailable ✅

.squad/decisions.md — Rule 6 updated from "5 sub-agent models" → "3 sub-agent models (Opus, Sonnet, Codex)". Consistent with the new charter. ✅

.squad/team.md — Description updated to reflect Opus-per-worker + 3-model sub-agent dispatch. ✅

---

Observations

🟡 Minor: Charter says "Do not use Gemini models" but doesn't explain why

Gemini models may be available in the squad toolset. Future workers reading the charter won't know whether this is a capability limitation (Gemini not available), a quality preference, or a policy decision. A one-line reason would help ("Gemini tool is not reliably available in this environment" or similar).

🟢 Nit: team.md lists only one role ("reviewer")

If the squad is intended to support fix workers alongside review workers, the team definition doesn't reflect that distinction. Not a problem for the current scope — just worth noting if the squad evolves.

---

✅ Verdict: Approve

Documentation-only PR. Changes are internally consistent, clearly written, and correctly update the consensus threshold. No production code affected.

🚢 Good to merge.