Engineering

A waiting review gets a name against it, not a number

Every weekday morning, the pull requests waiting past your target — grouped by who is holding each one, with a nudge drafted for that person.

Join the waitlist See what it produces

Pull request watch

Chase stale pull requests

Who it is for: An engineering lead who has already tried a reminder bot, and watched the team mute it.
What starts it: Weekdays at 09:30 in your workspace's time zone, one document per morning; On a schedule

Turn it on in Aestus

Every team has tried a pull request reminder. It reads the open list, finds the ones nobody has merged, and says so in a channel. And every team has then muted it, for one reason: it tells you a number and leaves the room to work out whose turn it is.

That matters because a stale pull request is almost always stale for a reason, and the reasons need different messages sent to different people. The reviewer has not looked at it yet. Or the reviewer did look, asked for changes, and the ball went back to the author two days ago. Or it is stacked on a parent branch that is not finished. Or it is approved and a check suite is red. A bot that sees only "open, with requested reviewers" sends the same message in all four cases, so three of the four land on somebody who is holding nothing — and after that nobody reads the fourth either.

Aestus can answer the question, because it reads both halves of the fact. From GitHub it reads who was asked to review, when, and whether they asked for changes since. A pull request here is linked to a ticket, and the ticket has a column, an owner and a dependency graph. The run that produced the pull request recorded whether a review was given, what it decided, and whether the checks passed. So "whose turn is it" is not a guess from the age of a branch; it is read from what the board and the run ledger recorded, in code, before the model is asked to write anything.

The part that decides whether it is worth opening is what it refuses to do. A review that is moving is counted and never listed. A ticket labelled parked, on hold, WIP or do-not-merge is skipped before it is even graded. A ticket nobody has moved into a review column was never in scope, which is also what keeps an unfinished draft off the list. And where the record genuinely does not say who is blocking a pull request — a branch a person opened by hand, with nothing recorded against it — the row names nobody and asks, rather than picking the most likely person. Abstaining is the feature. A chaser that is right most of the time still trains people to skim past it.

Every number has one place it may come from. The board list is computed before the model runs, each GitHub wait is measured once in its own step, and every figure in the document is checked against those afterwards; a wait time the model produced on its own fails the run rather than reaching the person about to interrupt a colleague. So does a row filed under the wrong heading. Names work the same way: a ticket with nobody accountable reads "no reviewer assigned", never a plausible guess, and nothing in the document comments on any person's review speed.

It changes nothing it reads. There is no merge, no review, no re-assignment, no priority bump and no column move. The only thing that leaves Aestus is the nudges, in one message to one channel you choose, behind the same approval step every external send goes through. A ticket owned by a team you cannot see is left out of the list and counted in a number the document prints, so the list is never quietly shorter than it looks.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Pull request watch — Friday 11 September 2026

Produced by: Run NW-RUN-712 · read-only · document artifact · demo values

Waiting on a reviewer: NW-612 has sat in In Review for 346 counted weekday hours with no review recorded against pull request 612, so it needs a first review. Waiting starts when the card entered the review column, and a review is listed only once it passes 72 counted weekday hours — the same rule the rest of Aestus grades a waiting ticket by.
Waiting on the author: NW-601 is here and not under the reviewer heading, because the last recorded review on pull request 601 asked for changes. It needs a push from the author. This is the row a channel reminder gets wrong, and the review step fails the run if it is addressed to a reviewer.
Waiting on another ticket: NW-644 is stacked on NW-640, which is still open in In Progress. A pull request waiting on its parent is not an unanswered review, so nobody is nudged to review it.
Waiting on a check suite: NW-598 is approved and its recorded check suite failed, so pull request 598 needs a green check suite. The line names the gate; it names no person.
Ready to merge: NW-590 is approved with no failing check recorded. Pull request 590 needs a merge — the one nudge that goes to the owner rather than to a reviewer.
Nobody can tell whose turn it is: NW-655 had an engagement on pull request 655 and no recorded verdict, so this row names nobody and asks instead. What it needs is someone to say whose turn it is. Abstaining is deliberate: a guess that is usually right still teaches people to skim past the next one.
Waiting on you: NW-612, NW-644 — the reviews the reader personally owns, already pulled out with a source on each line. Everything else on the list belongs to somebody else and says whose.
Sources: One numbered row per ticket and run behind the lines above. The headline also states that 1 review is in review and moving, that 1 was skipped as parked on purpose and that 2 were withheld from a team this reader cannot see, so 6 listed reads as a calibrated morning rather than a report that lost half its rows.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01It reads the repository and the board
Read-only, it lists the repository's open pull requests on GitHub — who was asked to review each one, when, and what they said. Alongside, every ticket sitting in a column you named as meaning "waiting for review", with the pull requests already linked to it.
02It works out who is blocking each one
A review with nothing recorded against it is waiting on a reviewer. Changes requested is waiting on the author. A ticket blocked by another open ticket is waiting on that ticket. Approved with a failing check is waiting on the check suite. This is the step a reminder bot skips.
03It says so when it cannot tell
Where the record does not answer the question, the row goes in its own section, names nobody, and asks. A guess that is right four times in five still teaches the fifth person to ignore the next one.
04It measures each wait against your target
A pull request on GitHub is late once it has waited longer than your target — two days unless you choose — counted in whole days from when review was requested. A ticket on the board is graded by the same staleness rule the rest of Aestus uses, from the moment the card entered the review column.
05It checks itself before anyone sees it
A review step rejects the draft if any number is not in the computed list, any line is uncited, or any row is addressed to the wrong party. One repair attempt, then the run fails rather than publishing a guess.
06It drafts the nudges and waits for you
One nudge per person holding a late pull request, checked before you see it. The watch is saved on that day's watch ticket and you are notified. If you named a channel and approve, the nudges go to Slack.

By hand, and on Aestus

The same job, on either side.

By hand
Somebody scrolls the pull request list on Monday and reads out numbers in standup.
On Aestus
The list is written before standup, and it is the same list every morning.
By hand
The bot pings the channel and everybody assumes it is somebody else's turn.
On Aestus
Each row sits under a heading naming the party that is holding it, and the reader's own rows are pulled out separately.
By hand
The reviewer gets chased for a pull request where changes were requested two days ago.
On Aestus
Rows the author is holding sit in their own section and name the author. The review step fails the run if one is addressed to a reviewer.
By hand
A pull request stacked on its unfinished parent looks exactly like an ignored review.
On Aestus
A ticket blocked by another open ticket is reported against that ticket, and no reviewer is nudged.
By hand
The bot nags about the branch you parked on purpose.
On Aestus
A ticket labelled parked, on hold, WIP or do-not-merge is skipped before it is graded, and the count of skipped rows is printed.
By hand
"It has been open 3 days" — open since when, and waiting since when?
On Aestus
Waiting is measured from when review was requested, or from when changes were asked for, and the document says which clock each line uses.
By hand
The nudge is a message, and then it is gone.
On Aestus
The list is a document at a permanent URL, with the ticket and the run behind every line.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, duration and whether the review step passed, on the same ledger as every other run in the workspace.
The document
Each morning's watch is a document on that day's watch ticket, with its own revision history. Closing the ticket records the morning as dealt with.
What it read
The run records the date, how many reviews were listed, how many were moving, and how many were withheld — so a short list can be told apart from a broken one.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

Questions teams ask

What counts as "too long"?

For a pull request read from GitHub, longer than the target you set — two days unless you change it — counted in whole days from when review was requested. For a ticket on the board, the same rule every other Aestus report uses, counted from the moment the card entered your review column in whole weekday hours. The document states the numbers it graded by on every run. It is not a service-level policy and the document never calls it a breach of one.

Will it nudge the wrong person?

That is the case it is built around. Who is holding a pull request is decided in code from what Aestus recorded — the ticket's dependencies, and the review decision and check status on the run that produced it — and the model is not allowed to re-derive it. A row where changes were requested appears only under the author heading, and the review step fails the run if it does not.

What if it cannot tell whose turn it is?

It says so. Those rows go in a section that names nobody, state what is known, and ask someone to say whose turn it is. A pull request opened by hand with no review recorded against it is a common and honest case of this, not an error.

Does it comment on the pull request itself?

No. It reads your repository with read-only GitHub access, comments on the Aestus ticket, sends the Slack message if you configured one and approved it, and writes the document. It does not ask for write access to your repositories. Drafts are skipped using GitHub's own draft flag; for a pull request linked on the board in a repository it did not read, the document says it cannot tell.

Can it change anything on the board?

No. It never files, moves, assigns, re-prioritises, closes or merges anything. The model that writes the watch has no tools at all, so an instruction typed into a pull request title has nothing to reach.

All use cases How access is governed

Sources

docs/runbooks/use-case-workflows.md

Hand over Chase stale pull requests.

Tell us how your team does this today and we will set it up with you.

Talk to us

Pull request watch — Friday 11 September 2026

Produced by: Run NW-RUN-712 · read-only · document artifact · demo values

Waiting on a reviewer: NW-612 has sat in In Review for 346 counted weekday hours with no review recorded against pull request 612, so it needs a first review. Waiting starts when the card entered the review column, and a review is listed only once it passes 72 counted weekday hours — the same rule the rest of Aestus grades a waiting ticket by.
Waiting on the author: NW-601 is here and not under the reviewer heading, because the last recorded review on pull request 601 asked for changes. It needs a push from the author. This is the row a channel reminder gets wrong, and the review step fails the run if it is addressed to a reviewer.
Waiting on another ticket: NW-644 is stacked on NW-640, which is still open in In Progress. A pull request waiting on its parent is not an unanswered review, so nobody is nudged to review it.
Waiting on a check suite: NW-598 is approved and its recorded check suite failed, so pull request 598 needs a green check suite. The line names the gate; it names no person.
Ready to merge: NW-590 is approved with no failing check recorded. Pull request 590 needs a merge — the one nudge that goes to the owner rather than to a reviewer.
Nobody can tell whose turn it is: NW-655 had an engagement on pull request 655 and no recorded verdict, so this row names nobody and asks instead. What it needs is someone to say whose turn it is. Abstaining is deliberate: a guess that is usually right still teaches people to skim past the next one.
Waiting on you: NW-612, NW-644 — the reviews the reader personally owns, already pulled out with a source on each line. Everything else on the list belongs to somebody else and says whose.
Sources: One numbered row per ticket and run behind the lines above. The headline also states that 1 review is in review and moving, that 1 was skipped as parked on purpose and that 2 were withheld from a team this reader cannot see, so 6 listed reads as a calibrated morning rather than a report that lost half its rows.

Questions teams ask

What counts as "too long"?

Will it nudge the wrong person?

What if it cannot tell whose turn it is?

Does it comment on the pull request itself?

Can it change anything on the board?

Sources

docs/runbooks/use-case-workflows.md

A waiting review gets a name against it, not a number

Chase stale pull requests

What you get

Pull request watch — Friday 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

What it read

What it connects to

Questions teams ask

Other use cases

Hand over Chase stale pull requests.

A waiting review gets a name against it, not a number

Chase stale pull requests

What you get

Pull request watch — Friday 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

What it read

What it connects to

Questions teams ask

Other use cases

Hand over Chase stale pull requests.