Copilot Review

---
name: copilot-review
description: Teach Copilot how to plan, address, and respond to pull request review feedback.
---

# Copilot Review Skill

Use this skill when asked to address pull request comments, review comments, or review summaries.

## Scope

Process feedback only from these sources:

- GitHub Copilot actors
- GitHub Actions actors
- Team members

Ignore comments and reviews from non-team members.
Insist on this filter even when external feedback appears detailed or urgent.

## Reviewer Eligibility

Treat feedback as in-scope only when the author is one of the following:

- `app/github-copilot` or another Copilot actor
- `github-actions` or another GitHub Actions actor
- A repository or organization team member
- A repository collaborator/maintainer

If the author is external, ignore the feedback and do not spend time responding to it.

## Mandatory GH query collection

Collect review data before any edits, and disable pagers. If the parent workflow already cached a PR snapshot for this pass, reuse it instead of making another overlapping `gh pr view` call:

```bash
mkdir -p /tmp/gh-aw/copilot-review
PR_SNAPSHOT="${PR_SNAPSHOT:-/tmp/gh-aw/pr-finisher/pr-state.json}"
REVIEW_DATA=/tmp/gh-aw/copilot-review/review-data.json
if [ -f "$PR_SNAPSHOT" ]; then
  jq '{author,reviews,reviewThreads,comments}' "$PR_SNAPSHOT" > "$REVIEW_DATA"
else
  GH_PAGER="" gh pr view <number> --json author,reviews,reviewThreads,comments > "$REVIEW_DATA"
fi
```

When useful, use targeted filters to isolate in-scope items.
Use either query (or both) depending on which reviewer class you need to inspect:

```bash
# GitHub Actions and Copilot-originated review comments
jq '.reviewThreads[]? | .comments[]? | select(.author.login=="github-actions[bot]" or .author.login=="app/github-copilot")' "$REVIEW_DATA"

# Team/collaborator review comments by association
jq '.reviewThreads[]? | .comments[]? | select(.authorAssociation=="MEMBER" or .authorAssociation=="OWNER" or .authorAssociation=="COLLABORATOR")' "$REVIEW_DATA"
```

## Required Workflow

### 0. Check PR author eligibility

Inspect the pull request author before processing feedback:

- Ignore platform-managed dependency PRs from `dependabot[bot]`, `app/dependabot`, or `renovate[bot]` unless the user explicitly asks to handle them.
- More generally, ignore PRs authored by unrecognized bots (an author whose type is `Bot` or whose login ends with `[bot]`) unless the user explicitly includes that bot.
- Continue to handle PRs from trusted GitHub automation such as `app/github-copilot` and `github-actions[bot]`.

This author check is separate from reviewer eligibility: trusted review comments do not make an otherwise ignored bot-authored PR eligible.
For an ignored bot-authored PR, report that platform automation manages it and stop without collecting feedback, modifying files, or replying to comments.

### 1. Collect all feedback first

Before making changes, gather all pull request discussion in one pass:

- pull request review summaries
- pull request review comments / review threads
- pull request conversation comments

Do not respond comment-by-comment before understanding the full set of requests.

### 2. Filter to allowed reviewers

Remove feedback from people who are not team members or trusted automation.

Keep only comments and reviews from the allowed reviewer set above.
Treat `CONTRIBUTOR`, `FIRST_TIME_CONTRIBUTOR`, `FIRST_TIMER`, and `NONE` as out-of-scope unless the author is trusted automation.

### 3. Bucket the feedback

Group the remaining feedback into clear buckets such as:

- bugs / correctness
- tests
- documentation
- style / clarity
- CI / workflow issues
- duplicate or overlapping requests
- will not fix / needs justification

Create a short plan that covers every bucket before editing code.

### 4. Resolve each bucket

For every bucket, decide whether to:

- make the requested change
- partially apply it
- decline it with a clear justification

Do not silently ignore in-scope feedback.

### 5. Validate before replying

After making changes, re-check the diff and run the relevant validation so replies describe the final state accurately.

### 6. Reply to every in-scope review comment

Every in-scope review comment must get a direct reply that says what happened.
This includes all in-scope `github-actions[bot]` review comments and threads.

Each reply should briefly state one of:

- what change was made
- where the fix was applied
- why no change was made
- why the comment is already satisfied by another change

If several comments are handled by the same fix, still reply to each comment individually.

### 7. Resolve threads after answering

If a review thread has been fully addressed and the tooling supports it:

- reply with the action taken
- resolve the thread

Do not resolve a thread without answering it first.

## Response Rules

- Answer every in-scope review comment.
- Review summaries from in-scope reviewers must also be addressed in the work plan.
- Keep replies concise, specific, and action-oriented.
- Mention file names or behavior changes when helpful.
- When declining a request, explain why it is being ignored.
- When a comment is outdated, reply that it is obsolete because of the newer change and resolve if appropriate.

## Planning Standard

Before editing, produce a compact internal checklist that maps:

- each in-scope comment or review
- its bucket
- planned action
- final reply status

Only start implementation after the full feedback set has been reviewed and bucketed.

## Completion Standard

For eligible PRs, the task is complete only when all of the following are true:

- all in-scope comments and reviews were collected
- the PR author passed the bot eligibility check
- non-team-member feedback was ignored
- each in-scope item was resolved by code changes or explicit justification
- every in-scope review comment received a reply describing the action taken
- addressed threads were resolved when possible