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/04-triage.md

Step 4: Triage

Sub-agent type: general-purpose; budget: 5 min per ≤5 threads (parent batches in waves of ≤5 if step 3 returned more).

Inputs

From step 3:

  • Classified thread table — { thread_id, file, line, author, author_class, severity, summary } per open thread.

  • Original PR context (description, recent commits to the affected files) for re-deriving from principles in oscillation cases.

Return contract

Table of rows, one per thread:

{ thread_id, action, rationale }

Where action ∈ fix | decline | escalate-to-user and rationale is a single line citing the rule from the rubric below that fired.

Procedure

For each thread, apply the rubric in this file in order:

  1. Reviewer-type policy — human-or-bot threads default to escalate-to-user unless the user explicitly scoped them in.

  2. ROI vs Risk — score and decide for copilot threads.

  3. Fix / Decline rule lists — match the finding pattern.

  4. Project-specific policy hooks — research repo conventions before applying a generic "fix".

  5. Conflicting-comments resolution — if the finding flips a prior round's edit, apply the oscillation rules; if the agent is about to re-do an edit it already reverted, hard-stop and escalate.

  6. Escalation rules — escalate on design-level tradeoffs, large/cross-cutting changes, or high-risk/irreversible actions.

Return { thread_id, action, rationale } per thread to the parent; step 5 consumes only the fix rows, step 8 consumes the full table.

Gotchas

  • Batch in waves of ≤5 per sub-agent invocation. Larger batches blur the rationale and overrun the 5-min budget.

  • Human / advanced-security default is escalate-to-user. Auto-replying or auto-resolving a human review thread hides unaddressed concerns and is socially wrong.

  • Cite the rule that fired in rationale — one line, concrete. "Style nit per rubric §Decline" is fine; "looks small" is not.

  • The oscillation hard-stop is non-negotiable. If the agent is about to make an edit it already reverted in a prior round, that's the unambiguous signature of an oscillation loop — escalate.

Triage Rubric

Decision rubric for whether to fix or decline each Copilot finding. The goal is correctness, not appeasement — decline confidently when warranted.

ROI vs Risk

Score every proposed change on two axes, then decide:

  • ROI = value of the fix MINUS the cost to implement MINUS the user's cost to review.

  • Risk = blast radius, reversibility, effect on unrelated code.

ROIRiskAction
Clear positiveLowFix unilaterally.
MarginalLowFix if cheap; otherwise decline with rationale.
Clear positiveHigh / IrreversiblePropose to the user first.
MarginalHighDecline.
Negative (over-engineering for hypothetical)AnyDecline.

Reviewer-type policy (foundation, not a nit)

Each thread's author (returned by 03-list-open-threads.ps1) drives who can decide it:

ReviewerDefault action
copilot-pull-request-reviewer / copilot-pull-request-reviewer[bot]Loop-owned — triage with the rubric below. (03-list-open-threads.ps1 reports the raw author.login, which may carry the [bot] suffix on some surfaces; match both forms.)
Human reviewerDefault escalate-to-user unless the user explicitly scoped them into the loop. Auto-replying or auto-resolving a human thread can hide unaddressed concerns and is socially wrong.
github-advanced-security / other automated botsDefault escalate-to-user unless the project has a documented suppression / fix convention you can follow.

Fix when the finding is...

  • A real correctness bug: use-after-free / lifetime violation, race that drops user intent, gating logic that skips legitimate transitions, missing link dependency, off-by-one, null deref, unhandled error path.

  • A cross-cutting concern with a clean local fix: moving a mutex one scope up, pulling a duplicated check into a helper.

  • Documentation / test-plan drift: PR description claims behavior the code no longer matches; comment block describes the wrong thing; test-plan checkbox is inverted vs. the code.

Decline when the finding is...

  • A purely hypothetical race requiring cross-class plumbing, where actual exposure is negligible. Cite the interleaving you ruled out.

  • Style, naming, or formatting. Out of scope for the review loop.

  • Suggestions to add abstractions ("introduce a strategy pattern", "extract an interface") that don't pay for themselves at the current scale of the codebase.

  • Suggestions that contradict an established project convention — consistency with surrounding code is usually more valuable than the suggestion in isolation.

  • Micro-optimizations in code that is not on a hot path.

Project-specific policy hooks

Some findings are decided by project policy, not by general correctness reasoning. Before applying a generic "fix", research the repo's own conventions first — .github/instructions/*.md files (often have an applyTo glob that pins them to the changed file's path), .github/skills/, AGENTS.md, CONTRIBUTING.md, CI config, and recent commits to similar files. Fan out multiple explore sub-agents when several axes need checking (lint, format, spell-check, license header, etc.) — don't invent answers. What looks like an obvious fix may violate a project rule:

  • Spell-check / dictionary findings. If the project uses a spell-checker (check-spelling, cspell, typos, or similar), inspect its config and recent commits to learn the local convention (reword the document, add a pattern/regex, extend a dictionary/allowlist, use an inline ignore). Follow that convention; don't invent a new mechanism.

  • Lint suppressions / inline ignore directives. Most projects require an inline rationale comment. Bare suppressions get pushed back.

  • License headers / file boilerplate. Project-specific format, often CI-enforced — copy the existing header from a neighbor file.

  • Test framework, mock library, formatter choices. Follow the convention of the surrounding test files; never introduce a new framework because Copilot suggested one.

Cite the project's config file or convention in your reply.

Conflicting comments — break oscillation early

Failure mode: round N "fixes" what comment A asked for; round N+1 comment B objects and asks to revert it. Blindly flip-flopping ships oscillation and burns rounds.

Resolution rules — apply in order, stop at the first that fires:

  1. Re-derive from principles. Pick the side that wins on the function's contract + surrounding patterns + user's stated preferences — not the latest comment.

  2. Prefer the position with the explicit rationale. Concrete failure modes (security, correctness, data loss, perf) win over stylistic positions.

  3. Prefer human comments over bot comments when they directly conflict.

  4. If still ambiguous, escalate to the user. Summarize both positions side-by-side with a recommendation; do not silently pick.

Hard stop: if you are about to make the same edit you reverted in an earlier round, stop and escalate. That is the unambiguous signature of an oscillation loop.

Reply hygiene

Every reply — fix or decline — states the reasoning. This makes the PR self-documenting and gives the next review visible context. Declined findings cite the prior round and explain why the existing form is correct, so the next reviewer doesn't raise it again.

Escalation rules

Stay in autopilot by default; escalate to the user when:

  • The finding identifies a design-level tradeoff with multiple reasonable resolutions and no clear winner.

  • The fix would be large or cross-cutting (hundreds of lines, new architecture, refactor across modules).

  • The action is high-risk or irreversible (force-push, deletion, credentials, production).

Otherwise, decide and proceed.

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