review-with-copilot

review-with-copilot

Send a diff to GitHub's Copilot CLI for a second-opinion review, then relay findings.

Non-negotiable rules

1. Confirm upload first. The diff is sent to GitHub Copilot's backend (same trust boundary as gh, but it's still an upload). On the first call in a session, tell the user what will be sent (branch, file count, +X/-Y) and wait for confirmation.
2. Refuse on sensitive paths. If the diff contains secrets.properties, .env, *.p12, *.keystore, GoogleService-Info.plist, google-services.json, or anything matching *secret*/*credential*/*token* — refuse and warn. Don't upload them even if the user says it's fine.
3. Relay, don't agree. Present as "Copilot says:" with a one-line triage (genuine / off / needs-verify) after. The user decides.
4. Non-interactive only. Always pass -p/--prompt. Non-interactive mode also requires --allow-all-tools (per the CLI's own help). Pair it with --deny-tool write so Copilot can't modify files during a review. Never start an interactive copilot session — it blocks the Bash tool.
5. When the target is a PR, always include existing comments. Before sending the diff, fetch every PR comment via gh — issue comments, review summaries (including CHANGES_REQUESTED), and inline review comments — and (a) inline them as context in the prompt so Copilot doesn't repeat them, and (b) relay them back to the user verbatim using the standard finding format. See "PR-comment fetch" below.
6. No Kotlin lint auto-format in a review flow. User-specific preference; same rationale as the Gemini skill.

Default invocation

BRANCH=$(git rev-parse --abbrev-ref HEAD)
BASE=$(git remote show origin 2>/dev/null | awk '/HEAD branch/ {print $NF}')  # usually main; dev for some repos
RANGE="$BASE..HEAD"
git diff --stat $RANGE

Tell the user: N files changed, +X/-Y lines. Branch <branch> vs <base>. OK to send to Copilot?

Once confirmed:

DIFF=$(git diff $RANGE)
copilot \
  --model gpt-5 \
  --allow-all-tools --deny-tool write \
  --no-color --log-level error \
  -p "You are doing a careful code review. Focus on:
- Correctness bugs and logic errors
- Race conditions or concurrency issues
- Silent failures / swallowed errors
- Missing edge cases
- API misuse

Do NOT comment on formatting/naming/comments unless something is actually wrong.
Be terse. 'bug:' for confident, 'might:' for speculative. Under 400 words.

## Diff
$DIFF"