copilot-pr-squad, reference · October 12, 2026

How copilot-pr-squad works

A reference for the series: what copilot-pr-squad does as of 0.5.2, how an hourly run passes work between agents, and where it still falls short.

A reference page for a series on copilot-pr-squad, a small team of AI agents, built on bradygaster/squad, that drives my GitHub Copilot coding-agent pull requests. New here? Start with Part 1.

What it does, as of 0.5.2

As of Oct 8. For what changed after, see Since 0.5.2.

Features
AreaWhat the squad does
Sort PRsA read-only script sorts every PR by what it’s waiting on (Copilot working, draft needs checking, needs a fix, reviewer comments open, ready, needs me) and names the agent that owns the next step. A run where nothing changed stops there.
Review draftsReviews each draft against its issue’s requirements and any briefs I wrote for it, with a design check on the first review.
Run the checksRuns the repo’s own lint, type and test commands on the PR’s latest commit, and tells a failure the PR caused from one main already has.
Track known issuesKeeps a list of known breaks on main, including flaky tests, each tied to its issue and matched by the failure’s text. A PR failing only on a tracked break isn’t sent to Copilot or to me; anything else failing beside it still is. When the issue closes as fixed, the squad asks just the PRs that show the break to merge main, and drops the entry once they all have the fix. A new failure on main comes to me once, naming an open issue if someone already filed it.
Instruct CopilotSends one @copilot comment per round with everything wrong at that commit. Every factual claim in it is checked first, and the posting script refuses text that wasn’t.
Answer reviewersJudges each reviewer comment, replies, and resolves a person’s comment thread only once a fix is verified.
Hand offMoves a finished draft to ready and @-mentions the people who already commented. Approval and merge stay mine.
Keep descriptionsRestores the PR description each time Copilot overwrites it, with a section showing where each requirement is met.
Queue workHolds a PR that would conflict with another until the earlier one merges, and assigns an issue to Copilot only once the PR or requirements it depends on are ready.
Back offStops instructing Copilot during an outage, and waits out a cancelled build instead of asking for a fix.
Steer itEverything I tell the squad lives in files checked into the repo, so an edit from any machine reaches the next run. An instruction stays on a PR until its latest commit satisfies it, such as “merge main, it has fix X”. A known break marks a failure on main as tracked. An order holds one PR until another merges, and an assign hands an issue to Copilot once a PR merges or its requirements are accepted. A review brief pins what a PR may touch. A config file sets watch-only or live per PR, and an ignore list takes a PR out of the squad’s hands.
ReportOne status report each run, a list of questions I answer in plain text, and a cost table per PR.

Inside an hourly run

The agents pass work to each other through files. Among the agent steps, only two write to GitHub, and both go through scripts. Before the agents start, scripts also post my answers from the question list, assign waiting issues to Copilot and resolve answered bot threads:

Which agent writes what, and the only writes that reach GitHubGitHub: the PR, its diff, CI checks, comments and review threadsCoordinatorReviewerTesterFact CheckerCommunicatorScribea script readsrestore script rewrites the descriptionCommunicator’s scripts: the @copilot comment,thread replies and resolves, the ready flipand the @-mention of reviewersRound folder: one per PR per round, on the machine that runs the squadbriefrestore notesreviewtriagegatefact checknudge,thread repliesEach seat reads the files written before it: brief, review and gate, nudge, fact check.The posting script refuses to post unless the fact check clears the exact nudge.PR ledger,run log,escalation ledger:committedStatus file: who eachPR is waiting onI approve, merge andanswer questions
Who writes what in a run. The two thick arrows are the only writes the agents make to GitHub; the dashed arrow is the read every run starts from. Everything else stays in files. Rai, called only on demand, is left out.

Where it falls short