copilot-pr-squad, part 1 of 6 · October 12, 2026
Building the process, not the feature
I stopped driving each Copilot PR by hand and built a team of agents that drives them for me. It got good the way a product does: watch it run, fix one thing, repeat. Building the process that builds the feature is now the job.
The short version
copilot-pr-squad is a small team of AI agents that drives my Copilot coding-agent pull requests. It’s built on bradygaster/squad, an open-source tool for running a team of AI agents through GitHub Copilot. Every hour it reviews each PR, runs the repo’s checks and tells Copilot what to fix next. Copilot still writes all the code, and I still approve and merge.
New to coding agents? How a Copilot PR works below covers the basics, and the glossary explains the rest.
40 PRs
worked by the squad since Sep 30. 21 have merged.
235 comments
to Copilot, written, fact-checked and posted by the squad without my sign-off on each one.
3.0h → 2.1h
typical wait after Copilot finishes, before the next step. Me before the squad, then the squad on scheduled runs.
35% cheaper
per run after the cost work, and about half the cost per PR on busy runs.
96 releases
in eleven days. Each mistake it made became a tested fix.
What changed for me
I stopped guiding Copilot through every round of every PR. Now I answer the few questions the squad can’t decide.
The lesson
When agents do the building, the job becomes building and tuning the process that builds the feature.
Where it’s going
More users and repos, and squads upstream that write the issues and designs it works from. See Part 6.
Building the process, not the feature
The Copilot coding agent can already write the code for a well-scoped issue. What it can’t do is run its own pull request: notice it went off track, check its work against what was asked, answer reviewers, and know when it’s done. Until now that was my job, one PR at a time, and it grew with every PR I opened.
This squad is my attempt to make that job a process instead. I don’t drive each PR any more. I write the rules the squad follows and the briefs that tell it what a PR may and may not do, and when the squad gets something wrong, I fix the squad. I don’t fix the PRs: the squad drives them, and Copilot writes every change.
That is the shift I think every engineer working with coding agents needs to make. The question stops being “how do I get the AI to write this feature?” and becomes “what process would get this feature, and the next ten like it, built well without me in every step?” This series is one worked example: what I built, how it got good, and what I’d carry into the next one.
Before and after
How a Copilot PR works
If you haven’t used the Copilot coding agent: there are two ways to start one of its sessions in the cloud. Assign it an issue, and it opens a draft pull request; or mention @copilot in a comment on that PR. Either way the session reads the ask, pushes commits and stops. It never decides it’s done. So every Copilot PR runs on the same small loop: someone reviews the push and, if it needs changes, writes an @copilot comment that starts the next session. The loop doesn’t change when the PR moves from draft to ready for review; that just brings more reviewers into it. Someone also has to make that move, and in the end approve and merge.
Before: me and a local Copilot
Before the squad, the cloud Copilot agent wrote the code, and everything around it was a team of two: me and a Copilot session on my own machine. For every PR, every round, I guided my local Copilot to review the diff, run the repo’s checks and write the @copilot comment listing what to fix, then waited for the next push and did it again. When a PR looked ready, I guided it to move the PR out of draft, tag reviewers and answer their comment threads. Copilot did the steps; I decided what came next and asked for it, every step of every round. Several PRs were open at once, so most of my day went to checking which ones had moved and guiding the next step.
Why the cloud agent, if I already had a local Copilot? For smaller fixes, the cloud agent gives every change the same repeatable path, even when I drive it by hand: assign the issue, and the branch, the PR and the session all live in the cloud. Doing the same changes locally means keeping a separate branch and working copy per change, spread across my machines, just to have several going at once.
After: the squad runs the rounds
Now an hourly run does those steps. Each run starts by checking whether anything changed; if not, it stops. Otherwise a script sorts every PR by what it’s waiting on, and each PR goes to the agent whose job that is.
The squad is seven agents, each with one job and a written charter: a short file describing what that agent does and doesn’t do.
| Agent | Job | Model |
|---|---|---|
| Coordinator | Runs the hour: reads each PR’s state and hands it to the right agent. Decides when to stop and when to ask me. | Opus 5.5 |
| Reviewer | Reviews a draft against what its issue asked for, and judges the comments other reviewers left. | Opus 5.5 |
| Tester | Runs the repo’s checks on the PR’s latest commit, and confirms a fix actually fixed its problem. | Sonnet 5 |
| Communicator | Writes the squad’s comments on GitHub: the comment to Copilot and replies to reviewers. Also moves a finished draft to ready. | Opus 5.5 |
| Fact Checker | Checks every factual claim in a comment before it can post. | Sonnet 5 |
| Scribe | Keeps the record: what was decided on each PR, the run’s log, and the list of questions for me. | Sonnet 5 |
| Rai | Screens text from outside comments before any of it reaches Copilot. Called only when needed. | Opus 5.5 |
The squad never pushes code to a PR, approves or merges. Everything it writes to GitHub goes through a script that checks it first.
In numbers
Since it first posted on Sep 30, the squad has worked 40 of my Copilot PRs. It ran in two ways. Manual runs, Sep 30 to Oct 5: I started each run myself, a few times a day at first and many times a day by Oct 5. Scheduled runs, from Oct 6: every hour except overnight.
| PRs worked | Merged in that period | |
|---|---|---|
| Squad, manual runs (Sep 30 to Oct 5) | 30 | 7 |
| Squad, scheduled runs (from Oct 6) | 30 | 14 |
| All squad PRs | 40, of which 20 were worked in both periods | 21 |
Of the 40, 17 are still open, 2 were closed without merging, and 8 were opened after the schedule began.
Comments. Before, my local Copilot drafted each @copilot comment, and I read and approved it before it posted: a median of four per merged PR. Now the squad drafts, fact-checks and posts them without waiting for me: 235 across its 40 PRs, a median of five per merged PR. I still steer what goes into them, through briefs, standing instructions and my answers to its questions, but I no longer sign off each one.
Waiting. Copilot itself works for about an hour on a typical PR. Most of a PR’s life is spent waiting for someone to look at what Copilot pushed and decide the next step. So the measure that matters is how long a PR waits after Copilot finishes before the next @copilot comment or reviewer ping.
| Who took the next step | Responses | Median hours | Within 2 hours | Over 12 hours |
|---|---|---|---|---|
| Me, before the squad (PRs from Sep 1) | 202 | 3.0 | 36% | 20% |
| Squad, manual runs (Sep 30 to Oct 5) | 170 | 4.2 | 27% | 26% |
| Squad, scheduled runs (from Oct 6) | 73 | 2.1 | 47% | 15% |
On scheduled runs, the squad cut the typical wait from my 3.0 hours to 2.1. On manual runs, it was slower than I had been on my own. Every scheduled wait over 12 hours ran across the overnight pause, which accounts for 8 hours of each; the rest was daytime waiting.
What these numbers don’t show.
- Time saved. I didn’t log my own time, and I spent much of the pilot building the squad.
- More output. I didn’t take on more work because of the squad, so I don’t count how many PRs were opened.
- Faster merges. None of the 8 PRs opened since the schedule began has merged yet.
- Waits for CI. I didn’t pull CI timings, so time spent waiting for checks counts as part of the wait for the next comment.
The squad posts from my account, so I tell its comments apart from mine by the marker it adds. The data covers every PR the Copilot coding agent opened for me in one team repo, 103 from Aug 6 to Oct 8.
What it gave me
Mostly, I stopped watching PRs. I no longer check each open PR for a new push, or guide my local Copilot through each review, comment and reviewer reply. My part shrank to the blue box in the hourly run diagram: approve, merge, and answer the squad’s questions.
Those questions arrive in one place. Each run ends with a status report that sorts every PR by who it’s waiting on: me, Copilot or CI (the automated build and test checks), the squad, or another PR. Anything for me states the problem in plain words and the actual choices, and I can answer in plain text, such as “nudge this” or “mention that reviewer”, for the next run to carry out.
It also does things my manual loop never did: every claim in a comment is fact-checked before it posts, every PR is checked against what its issue asked for, and the PR description keeps its record of how the PR meets the issue, even though Copilot rewrites the description on every session.
The rest of the series
The squad got here one fix at a time. The next five posts are the stories behind those fixes, and what I’d carry into the next loop.
- Part 2Watching it before trusting it96 small releases in eleven days, and write access earned one step at a time.
- Part 3Telling the loop what isn’t its problemMost wasted rounds came from asking Copilot to fix something it didn’t cause.
- Part 4Catching scope creep earlyAn agent loop repeats a bad early choice every round, so check scope first.
- Part 5Making it cheaperAbout a third cheaper per run, and roughly half per PR on busy runs.
- Part 6Lessons for your own loopWhat I’d carry into any agent process that runs without someone watching.
- ReferenceHow copilot-pr-squad worksWhat it does as of 0.5.2, inside an hourly run, and where it falls short.