Copilot Review

Create a GitHub PR, request Copilot review, poll until it arrives, and triage the results.

How it works

Use pr-with-copilot-review.sh for the entire flow. Do NOT create the PR separately with gh pr create and then try to poll.

Normal mode: create PR + review + poll

${CLAUDE_SKILL_DIR}/scripts/pr-with-copilot-review.sh --title "fix: foo" --body-file /tmp/body.md --base main

All arguments are forwarded to gh-post pr create --reviewer @copilot. The script then polls until Copilot's review arrives, outputting the review body and inline comments to stdout.

Pass the body with --body-file <path> (preferred) or --body-stdin.

Re-review mode: after pushing fixes

After pushing fix commits to an existing PR, trigger a new Copilot review and wait:

${CLAUDE_SKILL_DIR}/scripts/pr-with-copilot-review.sh --re-review https://github.com/owner/repo/pull/123

This records the current review count, runs gh pr edit --add-reviewer @copilot to trigger a new review, then polls until a new review appears (ignoring previous ones).

Poll-only mode: recovery for existing PRs

If the PR was already created and review already requested:

${CLAUDE_SKILL_DIR}/scripts/pr-with-copilot-review.sh --poll https://github.com/owner/repo/pull/123

Environment variables

• COPILOT_POLL_INITIAL — initial poll interval in seconds (default: 60)
• COPILOT_POLL_MAX — max poll interval (default: 300)
• COPILOT_POLL_ATTEMPTS — max attempts (default: 10)

Triage the review

Copilot reviews see the diff and file contents but lack project-specific knowledge about design decisions, test coverage, or runtime verification.

For each finding:

1. Cross-check against what you already know from the current conversation — code you've read, tests you've run, decisions made with the user
2. Classify under the finding-triage SSOT dispositions, applying each per its definition there — typically actionable, false-positive, or uncertain-validity
3. Present the triage to the user — don't dump raw review output

Respond to review

Each Copilot finding lives on an inline thread; that thread is the unit of response. Each reply carries the disposition its finding now holds, by its finding-triage slug, and a body of one or two sentences, on one line and without <!--, stating the reasoning and what the run will do about the finding. reply-threads.sh writes the slug at the front of the reply; do not begin the body with it.

The requirement gh-body-conventions § Exclusions places on a body's tokens binds each reply as it binds a body, except that a finding-triage disposition slug may stand as a bare name whichever repository the pull request is in.

A thread is due a reply when all of these hold:

• the run has triaged its finding;
• the thread's disposition in the list-pr-threads.sh listing is not the disposition the finding now holds, null included;
• the finding is not actionable, or its fix is pushed.

Reply within each due thread via reply-threads.sh — a single batch covers every due thread:

# 1. List the Copilot-headed threads, one JSON object per line. `head_id` is the
#    id `pr-with-copilot-review.sh` printed ahead of the thread's finding, and
#    `disposition` is the slug in the marker `reply-threads.sh` ends each reply
#    with, taken from the latest reply on the thread that carries one, or null.
${CLAUDE_SKILL_DIR}/scripts/list-pr-threads.sh {owner}/{repo} {number}

# 2. Build a JSONL file: one {"id": <head_id>, "disposition": "<slug>", "body": "<body>"} per due thread.

# 3. Send the batch.
${CLAUDE_SKILL_DIR}/scripts/reply-threads.sh {owner}/{repo} {number} < /tmp/replies.jsonl

When no thread is due a reply, post nothing.

Prerequisites

• gh CLI >= 2.88.0 (for --reviewer @copilot support)
• gh-post on PATH
• jq on PATH
• Copilot code review enabled for the repository (via GitHub plan + org/repo settings)
• Alternative: configure automatic Copilot review via Repository Rulesets (Settings > Rules)