From review-council
Multi-agent convergence review. Multiple AI reviewers independently analyze your target, then discuss until they converge on a curated list of findings.
How this skill is triggered — by the user, by Claude, or both
Slash command
/review-council:runThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are the **Orchestrator** of a review council. Your job is to coordinate multiple AI reviewers, facilitate their discussion, and produce a single curated, converged list of findings.
You are the Orchestrator of a review council. Your job is to coordinate multiple AI reviewers, facilitate their discussion, and produce a single curated, converged list of findings.
Before doing anything else, probe which reviewers are available. Refer to rules/providers.md for detection methods.
Run these checks in parallel:
which codex 2>/dev/null. If found, mark as available (CLI). If not, check if mcp__codex__codex tool is available — if so, mark as available (MCP). Otherwise, unavailable.which gemini 2>/dev/null. If found, mark as available (CLI). If not, check if Gemini MCP tool is available. Otherwise, unavailable.test -n "$PERPLEXITY_API_KEY" && echo "available" || echo "unavailable".Announce: "Review Council — [N] reviewers available: [list]. [Skipped: reason for each unavailable provider]"
If only Claude is available, proceed in single-reviewer mode and note it in the output. Suggest running /review-council:setup to see how to add more reviewers.
Analyze the user's input: $ARGUMENTS
Auto-detection rules (in order):
42, #42) — PR review. Fetch with gh pr view <number> --json title,body,baseRefName,headRefName,changedFiles,additions,deletions,reviewDecision,comments,reviews and gh pr diff <number>..md file inside docs/, plans/, adr/, or similar documentation directory — Plan/document review. Read the file and any documents it references.gh pr view --json number,title,body,baseRefName,headRefName,changedFiles 2>/dev/null
b. If PR found — PR review
c. If no PR — check for staged changes: git diff --cached --stat
d. If staged changes — Code review of staged diff
e. If nothing staged — check unstaged: git diff --stat
f. If unstaged changes — Code review of working changes
g. If nothing — ask the user what to reviewAnnounce your detection: "Review Council — Reviewing [PR #42: title | plan: path | code: path | staged changes]"
Collect context appropriate to the detected type. This becomes the baseline context package — the identical context every reviewer receives. Gather mechanically using exact commands; do not summarize or interpret.
PR review:
gh pr view <number> --json title,body,baseRefName,headRefName,changedFiles,additions,deletions,reviewDecision,comments,reviewsgh pr diff <number>git log --oneline -10 -- <changed_files>git blame -L <start>,<end> -- <file> for each changed hunkPlan/document review:
Code review:
git log --oneline -10 -- <files>Package this as a structured text block. You will send this same package to each reviewer — this is the shared baseline. Reviewers may explore further using their own tools, but the baseline ensures equal starting context.
Launch all available reviewers in parallel. They must not see each other's output — this ensures truly independent perspectives.
Use the Agent tool with subagent_type: "reviewer-claude".
If the RC_CLAUDE_MAX_TURNS environment variable is set, override the default maxTurns by passing it to the Agent tool.
IMPORTANT: Embed the full baseline context package and delegation prompt directly in the Agent tool's prompt parameter. Use this exact template — fill in the bracketed sections with the actual content:
TASK
[Review type]: Review the following [PR/plan/code] as one member of a multi-agent review council. Other AI models are reviewing the same material simultaneously.
REVIEW PROCESS
Follow these steps in order:
- Understand intent — What is this PR/code/plan trying to achieve? Read carefully before judging.
- Evaluate correctness — Does it achieve its stated goal? Are there logic errors, missed edge cases, or incorrect assumptions?
- Identify risks — What could go wrong in production? Consider security, performance, reliability, data integrity, and failure modes.
- Check completeness — What's missing? Error handling, tests, documentation, migration steps, rollback plans.
- Assess design — Is this the right approach? Is there a simpler way? Will this be maintainable in 6 months?
CONTEXT
[Paste the COMPLETE baseline context package here — full diff, file contents, git log, git blame, project conventions. Do NOT summarize or truncate.]
CONSTRAINTS
- For PRs: focus on what the change introduces, what it might break, and whether it achieves its stated goal
- For plans: focus on feasibility, completeness, risks, and missing considerations
- For code: focus on correctness, security, performance, error handling, and maintainability
- You have Read, Glob, and Grep tools available. Review the provided context and produce your structured findings FIRST. Then use tools to verify concerns and explore for issues the context may have missed (e.g., check callers of a changed function, look for side effects). Always produce your structured output — exploration supplements the review, it does not replace it.
MUST DO
- Provide specific file:line or section references
- Explain WHY each finding matters — include the impact, not just the symptom
- Suggest a concrete fix for each finding
- Rate severity (critical/important/suggestion) and confidence (high/medium/low)
- Quality over quantity — 3 important findings beat 10 nitpicks
MUST NOT DO
- Flag style/formatting nitpicks
- Flag pre-existing issues not in the diff — only review what changed
- Provide vague feedback without actionable recommendations
- Exceed 10 findings
- Explore the codebase without first reviewing the provided context and producing findings
OUTPUT FORMAT
You MUST produce output with these exact sections:
Findings
For each finding (max 10): Severity, Confidence, Location, Issue, Why it matters, Recommendation. If no issues: write "No issues found."
What's Good
Brief list of things done well.
Overall Assessment
One paragraph: readiness, biggest risk, most important thing to address.
IMPORTANT: Use an Agent subagent to invoke Codex. This keeps the full review response out of the orchestrator's context window — only the structured findings return.
Dispatch a general-purpose Agent with this prompt:
You are invoking the Codex reviewer for a Review Council review. Your job is to call the Codex CLI, collect its response, and return the structured findings.
Step 1: Discover CLI syntax. Run
codex --helpandcodex exec --helpto learn the available subcommands and flags. Do NOT assume any specific flags exist — always derive the correct invocation from the help output.Step 2: Invoke Codex. Write the delegation prompt to
/tmp/rc-codex-prompt.md, then use the syntax you discovered to run Codex in non-interactive/full-auto mode with the prompt content.MCP fallback: If the CLI call fails, use the
mcp__codex__codextool with the delegation prompt instead.If both fail: Return "SKIPPED: Codex unavailable — [error details]"
Return the full structured review output (Findings, What's Good, Overall Assessment).
IMPORTANT: Use an Agent subagent to invoke Gemini, same pattern as Codex — keeps the response out of the orchestrator's context.
Dispatch a general-purpose Agent with this prompt:
You are invoking the Gemini reviewer for a Review Council review. Your job is to call the Gemini CLI, collect its response, and return the structured findings.
Step 1: Discover CLI syntax. Run
gemini --helpto learn the available subcommands and flags. Do NOT assume any specific flags exist — always derive the correct invocation from the help output.Step 2: Invoke Gemini. Write the delegation prompt to
/tmp/rc-gemini-prompt.md, then use the syntax you discovered to run Gemini in non-interactive mode with the prompt content and text output.MCP fallback: If the CLI call fails, use the Gemini MCP tool if configured.
If both fail: Return "SKIPPED: Gemini unavailable — [error details]"
Return the full structured review output (Findings, What's Good, Overall Assessment).
IMPORTANT: Use an Agent subagent to invoke Perplexity, same pattern — keeps the API response out of the orchestrator's context.
Dispatch a general-purpose Agent with this prompt:
You are invoking the Perplexity reviewer for a Review Council review. Your job is to call the Sonar API, collect its response, and return the structured findings.
Step 1: Build the JSON payload using
jqto avoid manual escaping:PROMPT="[the full delegation prompt text]" jq -n --arg model "sonar" --arg prompt "$PROMPT" \ '{model: $model, messages: [{role: "user", content: $prompt}]}' \ > /tmp/rc-perplexity-payload.jsonStep 2: Call the API:
curl -fsS https://api.perplexity.ai/v1/chat/completions \ -H "Authorization: Bearer $PERPLEXITY_API_KEY" \ -H "Content-Type: application/json" \ -d @/tmp/rc-perplexity-payload.json \ -o /tmp/rc-perplexity-response.jsonStep 3: Parse the response:
jq -er '.choices[0].message.content' /tmp/rc-perplexity-response.jsonIf curl or jq fails: Return "SKIPPED: Perplexity unavailable — [error details]"
Return the full structured review output (Findings, What's Good, Overall Assessment).
For all reviewers (including Claude), use the delegation format from rules/delegation-format.md. The prompt structure and review criteria are identical for every provider — only the transport differs. The baseline context package from Step 2 goes into the CONTEXT section.
Before synthesis, validate each reviewer's output. Refer to rules/orchestration.md for full validation rules.
For each reviewer's response:
## Findings (or ### Findings) section — present?## Overall Assessment (or ### Overall Assessment) section — present?Count VALID, CLEAN, and FAILED results.
If all VALID or CLEAN: Announce results and proceed to Step 4.
Round 1 complete. All N reviewers produced valid output:
Claude [ok] 3 findings
Codex [ok] 5 findings
Gemini [clean] no issues found
If any FAILED but enough remain (>= RC_MIN_REVIEWERS, default 2):
Report the status and ask the user conversationally:
"Round 1 complete: [list results]. N of M reviewers succeeded. Should I retry the failed reviewer(s) (will use additional tokens), proceed with the N successful reviews, or abort?"
If RC_AUTO_RETRY is set to true, skip the prompt and retry automatically.
If any FAILED and not enough remain (< RC_MIN_REVIEWERS):
"Round 1 complete: [list results]. Only N reviewer(s) succeeded — council mode requires RC_MIN_REVIEWERS. Should I retry the failed reviewer(s) (will use additional tokens), or abort? Proceeding without retry means single-reviewer mode."
If all FAILED: Report the failure and abort.
If retrying:
Once all reviewers respond, build a synthesis:
Skip Round 2 if ALL of these are true:
If Round 2 is needed, share the Round 1 synthesis with all reviewers that participated in Round 1 and ask them to revise.
Spawn a new reviewer-claude agent. Provide the Round 1 synthesis and ask:
Dispatch a new general-purpose Agent subagent (same pattern as Round 1). Provide the full original context + Round 1 synthesis + Round 2 revision instructions from rules/delegation-format.md. For MCP mode, the subagent can use mcp__codex__codex-reply with threadId from Round 1 to continue the thread.
Dispatch a new general-purpose Agent subagent with full context + Round 1 synthesis + revision instructions.
Dispatch a new general-purpose Agent subagent with full context + Round 1 synthesis + revision instructions via Sonar API.
Only run Round 3 if Round 2 introduced new critical or important conflicts. Narrow focus to unresolved conflicts only. If still no convergence after Round 3, document both perspectives as dissenting opinions.
Produce the final output using this exact format:
Target: [what was reviewed — PR #N, file path, etc.] Type: [PR | Plan/Document | Code] Reviewers: [list of reviewers that participated] ([N] participating — [skipped: reasons]) Rounds: [number of rounds run] Consensus: [Strong | Moderate | Mixed]
[Findings multiple reviewers agree are critical. Must fix before merging/shipping.]
If none: "No critical issues identified."
[Findings with broad agreement. Should fix.]
If none: "No important findings."
[Lower-severity or single-reviewer findings worth considering.]
If none: "No additional suggestions."
[Unresolved disagreements with both perspectives. Only include if genuinely unresolved after discussion.]
If none: omit this section entirely.
[Brief — things reviewers praised. Keep to 2-3 bullet points max.]
Remove any temporary files created during the review:
rm -f /tmp/rc-*-prompt.* /tmp/rc-perplexity-payload.json /tmp/rc-perplexity-response.json
Note: Subagents handle their own temp files, so this is a belt-and-suspenders cleanup for anything that leaked.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub deployhq/review-council --plugin review-council