Skill: Review Council

Read-only review powered by a council of model-pinned reviewers. Changes are usually not 100% correct — this skill exists to catch what slipped through. The goal is not broad commentary; it is a short list of concrete issues where the council agrees, plus transparent disclosure of where they disagree.

Council Models

Spawn subagents with the model parameter to pin each to a different model. Use all three when available, at least two otherwise:

• GPT-5.5
• Claude Opus 4.6
• GPT-5.3-Codex

Each subagent receives the same system preamble:

You are an independent subagent for read-only code research. MUST stay read-only. Stay within the requested scope. Do not speculate. Do not suggest patches. For every finding, cite exact files and lines. Form your own view from first principles. Do not anchor to the provided context.

Workflow

Phase 1 — Scope

• Prefer the active pull request, current git diff, completed edits during the session, or an explicit file list from the user.
• If there is nothing to review, ask the user to point at a branch, PR, diff, or file set.

Phase 2 — Build a Change Summary

Before fanning out, build a preliminary orientation that each reviewer will receive. This is a starting point, not ground truth — reviewers are expected to contradict it if their own investigation leads elsewhere. Do not paste the raw diff — reviewers have tools to read code themselves.

The summary should include only:

1. Intent — what the change is trying to accomplish (from current plan, PR description, commit messages, or conversation context).
2. Changed files — list each file path with a one-line description of what was touched (e.g., "modified", "added", "deleted") — not what the reviewer should think about it.
3. How to inspect — tell the reviewers the branch/PR/commit info so they can use their tools to read the actual code.

Keep the summary under ~50 lines. Do not flag risk areas or pre-diagnose issues — leave reviewers to form independent assessments. They get better results reading code in context than scanning a pre-interpreted summary.

Phase 3 — Independent First-Pass Reviews

Spawn all subagents in parallel at once:

• One subagent per model using the model parameter. Prepend the system preamble to the reviewer prompt below.
• Do not show one reviewer's findings to another before this phase completes.

Phase 4 — Consensus Synthesis

Classify every finding into one of three buckets:

1. Consensus — two or more reviewers independently flag the same underlying issue. These are high-confidence findings.
2. Single-reviewer, strongly evidenced — only one reviewer flags it, but the evidence is concrete (compile error, failing test, clear correctness bug, security vulnerability, measurable regression). Keep these with a note that only one model flagged them.
3. Contested or speculative — a finding one reviewer flags that another reviewer's analysis implicitly or explicitly contradicts. Mention these briefly under "Contested" so the user can decide, but do not present them as confirmed issues.

Drop style chatter, linter-catchable nits, and low-confidence speculation entirely.

Phase 5 — Cross-Review (optional)

Trigger this phase when the user asks to "discuss", "debate", or "cross-review" the findings, or when Phase 4 produces contested findings that could benefit from a second look.

1. Share the anonymized synthesis (without attributing which model said what) back to each council agent.
2. Ask each agent: "Review these findings. For each, state whether you agree, disagree, or want to add nuance. Cite evidence."
3. Spawn all subagents in parallel at once.
4. Update the synthesis: promote contested findings to consensus if the cross-review resolves the disagreement, or note the persisting split.

This deliberation step is lightweight — it only re-examines the synthesized findings, not the full codebase.

…