AutoGineer
Generated banner for Copilot Pr Autopilot
Generated logo for Copilot Pr Autopilot

Copilot Pr Autopilot

GitHubOfficialFirst committed by yeelam-gordonDistributed by GitHub

  • Skill
  • Workflow
  • Software development
  • MIT
  • Low risk
  • Has scripts
Download ZIP

From the author

Copilot left 14 review comments on your PR — half are nits. Hours of fix → reply → resolve → re-request, and each round lands MORE comments. This skill runs loop engineering: auto-triggers Copilot Code Review via GraphQL (no @copilot mention), triages every open thread (Copilot, humans, advanced-security) with a fix / decline / escalate rubric, dispatches parallel fix sub-agents that obey the repo build/test/lint conventions, commits per iteration, replies+resolves citing the pushed SHA, then re-triggers until HEAD is reviewed with zero threads awaiting the agent's reply (remaining open threads are explicit hand-offs to the human — escalated declines, design tradeoffs). You merge a clean PR; the bot runs it. Trigger phrases: "address copilot comments", "run a copilot review loop", "fix this PR", "iterate on copilot feedback". Repo-agnostic, gh CLI + PowerShell. Full autopilot needs repo Triage/Write; external PR authors get single-iteration mode plus manual re-trigger (UI 🔄 or substantive-commit push).
— the description by yeelam-gordon

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Copilot PR Autopilot is a workflow-based skill designed to handle the repetitive cycle of addressing Copilot code review comments. It automates the process of triggering reviews, triaging findings, applying fixes, running build and test commands, and verifying convergence. The skill operates in a loop, ensuring that every Copilot finding is either fixed, declined with rationale, or escalated to a human reviewer. It is designed to be repository-agnostic and relies on the GitHub CLI and PowerShell to manage PR states and interactions.

What it does

  • Automatically triggers Copilot Code Review on a pull request.
  • Triage open review threads from Copilot, humans, and security scanners.
  • Dispatches sub-agents to apply fixes while adhering to repository build and test conventions.
  • Manages the commit and push cycle for each iteration of fixes.
  • Replies to and resolves review threads based on the agent's disposition.
  • Verifies convergence to ensure all threads are addressed or appropriately escalated.

When to use it

  • When a PR is functionally complete and requires a final automated correctness pass.
  • When a previous Copilot review has left numerous open threads that need systematic triage.
  • When you want to automate the repetitive 'fix-reply-resolve' cycle of PR reviews.

Advantages

  • Reduces manual effort in resolving large volumes of nit-picky review comments.
  • Maintains a clean audit trail by creating one focused commit per iteration.
  • Ensures fixes are validated against repository-specific build and test commands.
  • Provides a structured escalation path for design tradeoffs or human-specific feedback.

Usage examples

“address copilot comments”
The agent initiates the review loop, triages existing Copilot findings, applies necessary fixes, and pushes commits until the PR is ready for review.
“run a copilot review loop”
The agent triggers a new Copilot review, waits for the results, and begins the iterative process of fixing and resolving threads.
“fix this PR”
The agent analyzes the current PR state, identifies open review threads, and executes the fix-and-verify workflow to address all actionable feedback.
“iterate on copilot feedback”
The agent performs a single iteration of the review loop, applying fixes for current Copilot comments and reporting on the status of remaining threads.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/github/copilot-pr-autopilot/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip copilot-pr-autopilot.zip -d .agents/skills

Documentation by yeelam-gordon

Copilot PR Autopilot

Drive any GitHub pull request through repeated rounds of Copilot code review until the agent has done its job — every Copilot finding has a reply from the agent (fix-acknowledgement, decline-with-rationale, or explicit escalate-to-user hand-off). Remaining open threads, if any, are deliberate hand-offs to the human merge owner — they're not loop failures. Repository-agnostic — works on any repo that has Copilot Code Review enabled, run from a machine with gh CLI installed and authenticated (see Prerequisites).

When to Use This Skill

  • The user asks to "request Copilot review" or "run a Copilot review loop" on a PR.

  • A PR is functionally complete and the user wants a final correctness pass via repeated automated review rounds.

  • A previous Copilot review on the PR has left open threads that need triage, fixing, replying, and resolving.

When NOT to Use This Skill

  • The PR is still under active design — wait until the structure is stable; otherwise findings churn round-over-round.

  • The user wants human reviewer feedback, not Copilot's.

Prerequisites

  • gh CLI installed and authenticated against the target repository.

  • PowerShell on PATH — Windows PowerShell 5.1+ (powershell.exe) or PowerShell 7+ (pwsh). Both are tested.

  • Copilot Code Review is the primary use case (01-request-review.ps1 uses GraphQL requestReviewsByLogin to trigger Copilot). It is NOT a hard requirement — if 01-request-review.ps1 fails because Copilot isn't enabled on the repo / account, the agent can still drive existing review threads (human, advanced-security, etc.) to completion by running steps 3–8 once as a single iteration; just skip the trigger + wait. There is no auto-detect for "Copilot unavailable" — the agent makes that decision after the trigger fails (the script can't reliably tell "Copilot disabled" from "Copilot enabled but not yet triggered" from API state alone).

Permissions: who can run the full loop

The full multi-round autopilot (steps 1 → 9 → 1) needs Triage or Write permission on the target repo, because GitHub's only public API for adding the Copilot bot as a reviewer (requestReviewsByLogin) is gated on that permission. Verified against the public REST + GraphQL surface in this PR's commit history — there is no public-API path for bot reviewers without write permission.

You are…What works
Repo collaborator with Triage / WriteFull loop: 01 triggers Copilot, 02 waits, 04–08 triage / fix / reply, loop back to 01. Hands-off.
External PR author (no write permission)01 will throw a clear actionable error. Use -SingleIteration mode: address all current findings in one pass, then either click the UI 🔄 next to Copilot, or push a substantive commit (the synchronize event auto-triggers Copilot on most repos). Then re-run 02 to verify.

In single-iteration mode the loop's convergence boolean is Converged: true iff OpenThreadsAwaitingReply == 0 (the agent's side is done). The maintainer-side re-trigger then drives any additional rounds.

Every script dot-sources scripts/_lib.ps1 which runs Assert-GhReady on load: if gh is missing OR gh auth status fails, the script halts before any work with a single actionable error message naming the install command and gh auth login. The agent should surface that message to the user verbatim and stop the loop — do not retry or work around it.

Step-by-Step Workflow

The loop: steps 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9, then back to step 1 if Converged: false. Repeat the 1→9 round until step 9 returns Converged: true; only then run step 10 once and call task_complete. At every 10th round, the parent runs the round-cap recap gate before looping back — recap all prior rounds and stop if the loop has drifted out of the PR's original scope.

Each round runs steps 1–9; step 10 is a one-time cleanup after convergence. The parent agent coordinates; every sub-agent step runs in a fresh context with a bounded budget. Cross-cutting protocol (time-boxing, extension, single-iteration fallback): orchestration.md.

  1. Request review (parent) — see 01-request-review.md

  2. Wait for review (sub-agent, 20-min cap) — see 02-wait.md

  3. List + categorize open threads (sub-agent, 5 min) — see 03-list-threads.md

  4. Triage (sub-agent, 5 min per ≤5 threads) — see 04-triage.md

  5. Fix (sub-agents, parallel max 5, 5 min each) — see 05-fix.md

  6. Build + test per repo conventions (sub-agent, 10 min) — see 06-build-test.md

  7. Commit + push (parent) — see 07-commit-push.md

  8. Reply (always) + resolve (conditional) (sub-agent drafts, parent posts) — see 08-reply-resolve.md

  9. Convergence verify (sub-agent, 3 min) — see 09-convergence.md

    • Converged: false → loop back to step 1 for another round (re-trigger, wait, list, triage, fix, push, reply, re-check). Each round addresses Copilot's findings on the previous round's HEAD; the loop terminates as soon as Copilot has nothing new to say AND every open thread has a reply from the agent.

    • Converged: true → exit the loop, run step 10 once, call task_complete with the proof.

    • Every 10th round (10, 20, 30…) → run the round-cap recap gate before looping back. Recap ALL prior rounds against the PR's original scope and pick a verdict: CONTINUE, REVERT-AND-SHIP (drop drifted commits, ship the in-scope ones), or HAND-OFF (escalate to the user). This is the circuit breaker that stops a runaway bot-review loop.

  10. Cleanup outdated (parent, post-convergence, once) — see 10-cleanup.md

Convergence is computed by scripts/02-check-review-status.ps1 as a single Converged: true boolean. Do not call task_complete until it returns true; print the proof (HeadOid, LatestCopilotReview.commitOid, submittedAt) in the completion message.

Gotchas

The bundled scripts enforce the hard correctness invariants (trigger landing via copilot_work_started event id, Converged requiring HEAD-match + zero-awaiting + at-HEAD review, single-iteration fallback semantics, PR-state guard). Trust them — don't re-derive. The notes below cover decisions the scripts can't make for you:

  • Reply to every open thread; resolve only when the loop owns the disposition. For fix and decline threads, reply + resolve. For escalate-to-user threads, reply with the analysis but leave the thread OPEN (08-reply-and-resolve.ps1 -NoResolve) so the human merge owner can act on it. See 08-reply-resolve.md.

  • Copilot threads are loop-owned; human / advanced-security / other-bot threads default to escalate-to-user. Auto-resolving a human review thread can hide unaddressed concerns. See 04-triage.md for the rubric.

  • One focused commit per round, not one per PR. Bundling rounds destroys the audit trail of which finding drove which change and breaks git bisect. See 07-commit-push.md.

  • Build/test/lint with the repo's own commands (per its CONTRIBUTING / AGENTS / README / package.json / Makefile) before pushing a fix. Discovery procedure: 06-build-test.md.

  • Push back with written rationale when a Copilot finding would over-engineer the design for a hypothetical edge case. Auto-accepting every suggestion erodes the design — see the decline path in 04-triage.md.

  • Scripting traps (gh api graphql -F type-coercion, git stash push -m positional parsing, the three GraphQL traps for the reviewer mutation) are documented in references/api-quirks.md. Read before modifying any script.

Troubleshooting

IssueSolution
Script throws prerequisite missing — gh CLI is not on PATHInstall gh (winget install GitHub.cli on Windows; brew install gh on macOS; package manager on Linux; or download from https://cli.github.com). Then gh auth login. Surface the message to the user and STOP the loop — do not retry.
Script throws prerequisite missing — gh CLI is not authenticatedRun gh auth login. STOP the loop until the user completes auth.
Trigger fails or no copilot_work_started event landsPush a substantive (non-whitespace) commit — auto-assign on synchronize is the most reliable trigger. Persistent failure indicates Copilot Code Review may not be enabled on the repo / account (check repo Settings → Code & automation → Copilot, or account-level Copilot Pro/Pro+).
No new review after waiting ~10 minQuiet-period after recent dismissal or trivial-diff suppression. Push a substantive commit and retry. Do not blindly re-run 01-request-review.ps1 — it reports InFlight while Copilot is still a requested reviewer.
Outdated-but-unresolved threads in the open listExpected: unresolved state is the source of truth. Reply + resolve them like any other open thread. 10-cleanup-outdated.ps1 is only a final safety net.
Unsure whether to fix or decline a findingSee references/04-triage.md.
Need a reply phrasing for "fixed", "declined", or "drift"See the templates under templates/ — reply-fix.md, reply-decline.md, reply-drift.md, reply-partial.md.

References

Files

references/api-quirks.md

GitHub API Quirks (Verified)

API behaviors that matter for the Copilot review loop. All verified against the current API surface — read this before reaching for an alternative API or modifying the bundled scripts.

GraphQL trigger — requestReviewsByLogin is the supported path

mutation($p: ID!) {
  requestReviewsByLogin(input: {
    pullRequestId: $p,
    botLogins: ["copilot-pull-request-reviewer"]
  }) {
    pullRequest { number }
  }
}

Verified empirically against personal repos without Copilot Pro AND org repos with Copilot Enterprise. Works for both initial-add and re-request (no special re-request mutation).

Three GraphQL traps:

  1. Mutation is requestReviewsByLogin, NOT requestReviews. RequestReviewsInput (used by requestReviews) does not expose a botLogins field, so it can't request a bot reviewer at all — botLogins is the central field on requestReviewsByLogin.

  2. Field is botLogins, NOT userLogins. The latter returns Could not resolve user with login 'Copilot'.

  3. Slug is copilot-pull-request-reviewer (the App slug). The display login Copilot returns Could not resolve bot with slug 'Copilot'.

Verify success via a new copilot_work_started event on the issue's events feed — GET /repos/{o}/{r}/issues/{n}/events (see SKILL.md Gotchas "HTTP 200 / exit 0 is NOT proof"). Empirically this event type IS exposed on the /events endpoint (verified across 20+ trigger rounds on PR 236); it is not timeline-only. 01-request-review.ps1 enforces this by comparing the event id (monotonic) before and after the trigger.

Other trigger paths — DO NOT USE

  • requestReviews with botLogins → input type rejects the field. Don't try variants.

  • REST POST /pulls/<n>/requested_reviewers with reviewers[]=Copilot → can return HTTP 201 while silently dropping the bot. Not used by the script.

  • gh pr edit --add-reviewer Copilot → returns 'Copilot' not found on current gh. Not used by the script.

GraphQL latestReviews — stale cache, do NOT use

# DO NOT — stale projection:
pullRequest(number:$pr){ latestReviews(first:50){ nodes{...} } }

# USE INSTEAD — always current:
pullRequest(number:$pr){ reviews(last:100){ nodes{...} } }

latestReviews is a "latest per user" projection with stale-cache behavior: a fresh Copilot review can be absent for several minutes after submission, while reviews(last:100) reflects it immediately. Using latestReviews for in-flight or convergence checks causes the script to operate on an obsolete commit OID — either falsely declaring convergence or timing out for a review that already exists.

02-check-review-status.ps1 uses reviews(last:100) filtered client-side to the Copilot reviewer login. It also emits a stderr warning when the result is exactly 100 reviews, so the caller knows the boundary was hit and the latest Copilot review COULD be older than the window — practically only possible if 100+ non-Copilot reviews landed after the last Copilot review, which doesn't happen in normal use. If you ever see the warning and the loop misbehaves, fetch the full review list manually:

gh pr view <n> --json reviews --jq '.reviews[] | select(.author.login | test("copilot-pull-request-reviewer"))'
Tie-break for multiple Copilot reviews

When more than one Copilot review shares the same submittedAt (rare server-side clock collision under burst re-triggers), the script first prefers the review whose commit.oid == HEAD, then falls back to a stable sort. The intent is "the review that matches the current code is the one the agent should reply to" — preventing a stale-OID review from winning the tie and falsely flipping ReviewAtHead to false.

Reply + resolve mutations — both work

mutation($tid: ID!, $body: String!) {
  addPullRequestReviewThreadReply(input: {
    pullRequestReviewThreadId: $tid,
    body: $body
  }) { comment { id } }
}

mutation($tid: ID!) {
  resolveReviewThread(input: { threadId: $tid }) {
    thread { isResolved }
  }
}

isOutdated ≠ isResolved — current unresolved state is truth

A thread can be isOutdated: true (Copilot's comment points at lines that have since changed) while still isResolved: false. These threads:

  • Still need reply + resolve in the per-round loop. A thread can become outdated mid-round when your own fix shifts the cited lines. Filtering on !isOutdated would silently drop those threads, leaving the PR's open-conversations list non-empty even after the underlying code is fixed.

  • 03-list-open-threads.ps1 therefore lists every unresolved thread with no isOutdated filter.

  • 10-cleanup-outdated.ps1 is a safety net only — for the rare case where a thread becomes outdated AFTER your last per-round fetch.

Review latency — don't poll faster than ~3 min

Copilot reviews typically post 3–6 minutes after the request, occasionally up to ~10 minutes. There is no progress signal; polling more often than every ~3 min wastes API budget without making the review arrive sooner.

gh api graphql -F coerces strings — use -f for String!

The gh CLI distinguishes its two flag forms:

  • -F key=value — type inference. Values parsing as int, bool, or null are sent as that JSON literal.

  • -f key=value — always sends as raw string.

For any GraphQL variable declared String! (e.g. owner, repo, body, tid, after), use -f at call sites. A reply body that happens to be "true", "null", or all digits would otherwise be coerced and the call fails with a type error. Keep -F only for genuinely numeric or boolean variables (e.g. pr: Int!).

Note: the shared Invoke-Gh wrapper may internally rewrite -f field=<body> into -F field=@<tempfile> when the body contains embedded " (Windows PowerShell 5.1 native-arg quoting bug — see below). Even via @file, -F still applies type inference to the file content (gh's documented behaviour) — this rewrite is safe only because the rewrite trigger ("body contains "") guarantees the content is a string that no JSON literal (123, true, null, etc.) would match. Treat this -F ...=@file usage as an internal transport detail of the wrapper, not as permission to use -F ...=@file for arbitrary strings at call sites.

# Wrong — body could be coerced AND, under Windows PowerShell 5.1,
# any embedded `"` in $Body will be mis-split by the native-arg
# passer (gh sees a truncated body or a "received N args" error).
gh api graphql -f query=$q -F body=$Body

# Right — go through Invoke-Gh / Invoke-GhGraphQL. The shared helper
# auto-rewrites `-f field=<body>` and `-F field=<body>` pairs whose
# body contains `"` to `-F field=@<tempfile>` so the value is read
# from disk and never appears on the command line. This works
# identically on Windows PowerShell 5.1 and PowerShell 7+.
Invoke-GhGraphQL -GhArgs @('-f',"query=$q",'-f',"body=$Body") -Context 'reply body'

Calling gh directly (e.g. via & gh ... or raw gh api graphql) bypasses the cross-version tempfile rewrite — if your value contains " you'll re-introduce the PowerShell-5.1-only splitting bug. Always funnel gh calls through Invoke-Gh / Invoke-GhGraphQL.

Native gh exit codes bypass $ErrorActionPreference

gh is a native executable, not a PowerShell cmdlet, so a non-zero exit does not throw even when $ErrorActionPreference = 'Stop'. Without an explicit check the script will print misleading success messages after a failed API call, and the loop will falsely declare convergence on auth issues, rate limits, or transient 5xx.

Additional trap: gh api graphql can exit 0 for an HTTP 200 whose JSON body carries a top-level errors array. Treat that as a failed call too.

The shared helpers in scripts/_lib.ps1 (Invoke-Gh and Invoke-GhGraphQL) run gh via & gh @args with stderr redirected to a temp file (2>$errFile), then read $LASTEXITCODE and return {ExitCode, Stdout, Stderr}. Invoke-GhGraphQL additionally parses the GraphQL errors array on the response body and throws on either failure mode. All bundled scripts dot-source _lib.ps1 and use these wrappers — do the same in any new script.

git stash push argument order

git stash push -m "local-build" -- src/path/a src/path/b   # correct
git stash push -- src/path/a src/path/b -m "local-build"   # SILENTLY drops -m

The -m MUST come before the -- path separator.

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by
GitHub avatar of yeelam-gordonyeelam-gordon
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/copilot-pr-autopilot · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
yeelam-gordon

AutoGineer is not affiliated with or endorsed by yeelam-gordon or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download copilot-pr-autopilot.zip