copilot-pr-squad, a series in 6 parts
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. These six posts are how it got good, and what I’d carry into the next one.
The posts
- Part 1Building the process, not the featureI stopped driving each Copilot PR by hand and built a team of agents that drives them for me.
- 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.
Glossary
| Term | Meaning |
|---|---|
| Copilot coding agent | GitHub Copilot working on an issue assigned to it: it opens a draft PR and pushes commits, one session per @copilot comment. |
| bradygaster/squad | The open-source framework the squad is built on: a team of agents with written charters, run by a coordinator. |
| Run (tick) | One hourly pass of the squad over every PR. The squad’s own files call it a tick. |
| Round | One cycle on one PR: review, checks, one comment to Copilot, then wait for its next push. |
| Watch-only (shadow mode) | The squad does everything except write to GitHub, and records what it would have posted. |
| Review brief | A short file I write for one issue that pins what its PR may touch. |
| Known break | A failure on main, or a flaky test, that is tracked by an issue, so the squad doesn’t send it to Copilot. |
| Automation | A saved agent task that the GitHub Copilot app runs on a schedule. The squad’s hourly run is one. |