copilot-review

# 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