Skip to main content
skill CX Codex

debate-review — Claude Code skill: two-model PR review with debate

Two AI reviewers examine a PR or MR and debate findings before posting inline comments. One spots issues, the other pushes back or adds observations, then the first makes the final call. Output as comments on the forge or printed.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add amElnagdy/review-skills --skill debate-review -a claude-code
Open on GitHub

What debate-review does

Run one command and the skill orchestrates two independent sessions in sequence. The main reviewer reads the diff and flags problems. The debate reviewer challenges those findings or surfaces new ones. Then the main reviewer decides what lands: a single review with inline comments posted to GitHub, GitLab, or Azure DevOps from your account—or printed to stdout.

Works with GitHub (gh), GitLab (glab), and Azure DevOps (az). Posts as a non-approval review or comment; never approves or requests changes. Point it at an existing PR by URL or number, or run --local on an uncommitted branch. On Azure DevOps, the review becomes multiple inline comment threads plus one closed summary thread.

Needs Node 18+, Git 2.31+ for Azure DevOps, and the delegate-skills skill installed to define two reviewer lanes. Pick different implementations—the debate only works if the second model avoids the first one's blind spots. A run takes minutes; send it to the background and relay the posted URL when done.

What it helps with

  • Get a second opinion from a different model before merging
  • Surface overlooked issues by having two reviewers debate
  • Post a code review without manually reading the diff yourself
  • Review a local working tree before pushing a PR

Example prompts for the agent

  • Run node "<skill-dir>/scripts/review-pr.mjs" 42 to review PR number 42 in the current repo
  • Run node "<skill-dir>/scripts/review-pr.mjs" --local --base main for a local review of the current branch against main
  • Use --dry-run to print the review instead of posting it

How to install debate-review

1Skills CLI (Vercel)

npx skills add amElnagdy/review-skills --skill debate-review -a claude-code

2Manually: put the files in place

~/.claude/skills/debate-review/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/debate-review/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about debate-review

How do I install debate-review in Claude Code?

Run npx skills add amElnagdy/review-skills --skill debate-review -a claude-code, then open ~/.claude/skills/debate-review/SKILL.md and follow the setup steps.

What does debate-review do?

It runs two reviewer sessions: the main reviewer analyzes the PR diff and identifies issues; the debate reviewer challenges those findings or adds new ones. The main reviewer then makes the final call, and one review with inline comments is posted to the PR or MR.

What Node version and CLI tools are required?

Node 18+, Git 2.31+ for Azure DevOps, and an authenticated CLI: gh for GitHub, glab for GitLab, or az for Azure DevOps. You also need the delegate-skills skill installed to define the two reviewer lanes.

Source text

SKILL.md · MIT
---
name: debate-review
description: Two-model debate review of a GitHub PR, GitLab MR, Azure DevOps PR, or local working tree, posted as inline comments or printed. Use for any PR/MR review request, or a local review before a PR exists.
license: MIT
compatibility: Requires Node 18+, Git 2.31+ for Azure DevOps, `gh` (GitHub), `glab` (GitLab) or `az` (Azure DevOps) authenticated, and delegate-skills installed for the main/debate lanes.
metadata:
  version: 0.2.0
---

# debate-review

Two models argue before anything is posted. A main reviewer finds issues. A debate reviewer tries to
knock them down and may add its own. The main reviewer then makes the final call, and one review with
inline comments lands on the PR or MR. It posts from the user's own `gh`, `glab` or `az` account as a
non-approval review or comment. It never approves and never requests changes.

You are the orchestrator. You run one command and relay the result. You do not review the diff
yourself, and you do not touch the PR.

## Run it

```bash
node "<skill-dir>/scripts/review-pr.mjs" --local [--base <ref>]
node "<skill-dir>/scripts/review-pr.mjs" <pr-url | number> [--dry-run]
```

- If the user wants a review and there is no PR/MR URL, run `--local` from the repo (or `--repo-dir`). Do not invent a URL. Relay stdout. `--local` never talks to a forge and rejects non-UTF-8 Git paths rather than decoding them lossily.
- `<pr-url>` is a GitHub `/pull/N`, GitLab `/-/merge_requests/N`, or Azure DevOps
  `/_git/<repo>/pullrequest/N` URL (`dev.azure.com` or the legacy `*.visualstudio.com`). A bare number
  resolves against the cwd's `origin`, including Azure DevOps https and `ssh.dev.azure.com:v3/` remotes.
- `--dry-run` prints a live PR review instead of posting it. It does not combine with `--local`.
- Azure DevOps needs `az` logged in (`az login`) with access to the project. No extension is required,
  the script talks to the REST API through `az rest`. A review there is N inline comment threads plus
  one closed summary thread, since Azure DevOps has no single review object; the alert blockquotes
  render as plain quotes, which still read.
- The reviewers are two delegate-skills lanes, `review-main` and `review-debate`. If either is missing
  the script says so. Add them with `delegate-setup`. Pick two different implementers, since the debate
  is only worth something when the second model doesn't share the first one's blind spots (main
  `claude` or `grok`, debate `codex` at high effort is a good pair). For a one-off, pass
  `--main <implementer>` or `--debate <implementer>`. Only implementers whose relay has `--read-only`
  are accepted. These two lanes belong to the reviewer. Don't point them at a lane you use for other
  work, such as a plan-debate lane.
- `--check` starts each reviewer on a one-line read-only brief and prints `ok` or `FAIL` with the reason per role, exit `1` on any failure. Run it once on every machine after setting up the lanes; it catches a reviewer that is not installed, not signed in, out of quota, or refused by its sandbox before a PR waits on it.
- Exit code `3` means this head sha already has a debate-review. Re-run with `--force` to post again.
- A run takes minutes, since it is two or three implementer sessions back to back. Run it in the
  background and report the printed URL when it finishes. Don't poll tightly.

All flags: `--help`. Contracts: [references/schema.md](references/schema.md). What gets posted:
[references/comment-format.md](references/comment-format.md). The reviewer briefs live in `assets/prompts/`
and the script fills them in; you don't need to read them.

## After it posts

Each posted comment carries a `<!-- debate-review:<id> status=... -->` marker. `babysit-pr` handles
GitHub and GitLab rounds (verify, fix blockers, reply, resolve). It cannot harvest Azure DevOps yet,
so relay Azure findings directly to the user. Don't act on the findings yourself unless asked.

## Artifacts

`~/.cache/debate-review/<owner>__<repo>/<N>/<head>/` holds `run.json` (all three documents, timings,
what was posted) plus `main/`, `debate/`, and `final/`, each with the brief sent and the relay's
`result.json`.
`--local` writes under `~/.cache/debate-review/local/<repo>/<branch>/<head>/` instead.

© amElnagdy · MIT · amElnagdy/review-skills

Similar skills

All skills for Code review and refactoring →

From the same set2

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor