Engineering
Six open pull requests and nobody knows whose turn it is
The review queue, ordered by age and named by who is blocking it, posted every morning.
What the worker does
An AI worker can manage the queue around code review without touching the code. Each morning it reads open pull requests through the GitHub connection and posts an ordered queue showing how long each has been open, which reviewer has not responded, which have failing checks, and which change code without changing tests. Reviewing and merging remain entirely human actions.
- Runs
- Every weekday morning
- Connections
- GitHub, Slack, Linear
- Never automated
- The review itself
Pull requests do not stall for interesting reasons
They stall because the requested reviewer was on call, then went on holiday, and the author has moved on to something else and stopped chasing. Nobody is blocking on purpose. There is simply no place where the queue is visible, so the oldest pull request is invisible precisely because it is old.
Every fact needed to fix this is in the repository, and none of it requires understanding the diff.
What the morning queue shows
| Column | Why it is there |
|---|---|
| Age in days | The oldest item is the one everyone has stopped seeing |
| Waiting on | Names the specific person, not the team |
| Check status | A red build means the author is blocking, not the reviewer |
| Tests touched | Flags diffs that change code with no test changes at all |
| Linked issue | Shows whether the pull request closes committed work |
| Size | Files and lines changed, because a large diff needs a scheduled slot |
The rules worth putting in the skill file
The queue is only useful if it reflects how your team has agreed to work.
What counts as stale
Two days for a small team shipping daily, a week for a team on a fortnightly cadence. The worker escalates against your number, not a default.
Who gets named
Some teams want the individual reviewer named, others want the team. Naming an individual is more effective and more uncomfortable, and that is a decision for the team to make deliberately.
What to do with drafts
Draft pull requests either belong in the queue as visible work in progress or are noise. Say which, or the queue fills with things nobody expects to review.
Where it posts
The delivery is always a comment on the task. Add the Slack connection if the queue should also land in the channel where people actually look in the morning.
The queue against the review
The worker handles
- Sorting by age and naming who is blocking
- Reporting failing checks and unmerged approvals
- Flagging code changes with no test changes
- Posting the queue where the team will see it
Engineers handle
- Whether the change is correct
- Whether the approach is right
- Whether the missing test matters here
- Approving and merging
Questions people ask
+Does the worker comment on our pull requests?
No. It delivers the queue as a comment on a Polaris task, and optionally posts to a Slack channel if you have given it the Slack connection. The repository is read, not written to.
+Is flagging untested diffs useful, or just noise?
It is a signal rather than a verdict. Plenty of legitimate changes touch no tests, including copy changes and configuration. The flag exists so a reviewer notices before merging, not so a rule can block the merge.
+How is this different from a bot that posts reminders?
A reminder bot repeats a fixed message. A Polaris worker is briefed in a skill file you write, so it applies your definition of stale, your escalation rules and your position on drafts, and each run is logged with what it did.
+What if reviewers ignore the queue?
Then you have a prioritisation problem rather than a visibility one, and the queue at least makes it measurable. Teams often use the age column in a retrospective, which is a conversation the data makes possible.
Related
The engineering work that is not writing code
Five jobs that sit between an engineer and the code, and what an AI teammate does with each.
The two hours before planning that nobody schedules
Carry-over, gaps and blockers assembled the day before, so the meeting is about commitment.
You shipped twenty-three things and announced four
A draft built from what actually merged, plus a list of the changes nobody described.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.
Connect Slack to Polaris
Six scopes, no access to direct messages, and a bot that only reads the channels somebody invited it into.
Cloud agents versus local agents
Most teams end up running both. The useful question is which work belongs where.
Hire an AI QA engineer
Fourteen vague reports go in, fourteen tickets with steps, expected behaviour and a severity come out, with the three duplicates already merged.