---
title: "Pull Request Review Desk Workflow With AI Agents | Kylon"
description: "How a review desk walks pull requests against a pinned checklist, keeps a per-file ledger and handles push notices and checklist amendments in one Kylon room."
url: "https://kylon.io/use-cases/pull-request-review-desk"
language: "en"
---
[HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Pull Request Review Desk: Every Changed File Checked Against the Pinned Checklist
Use Case8 min read
# Pull Request Review Desk: Every Changed File Checked Against the Pinned Checklist
Every changed file in a pull request is walked against a pinned checklist, four ledger fields are recorded per file, a blocker gets one tracker issue the first time, and push notices and amendments re-walk exactly what they should. The desk lead approves each review.
[Get started](https://app.kylon.io/sign-up)
Kylon TeamProduct
November 6, 2026
## Some changes need the same careful read every time
A review desk exists for code that cannot be skimmed: authentication, payments, data migrations. The desk pins a checklist version, walks every changed file in a pull request against it, and records four fields per file in a ledger: the checklist item, the result, a note and the commit reviewed. A finding goes in the review. A blocker also gets an issue in the tracker, but only the first time that finding becomes a blocker.
The pull requests are in GitHub, the pinned checklist is a Notion page, the ledger is an Airtable base, blocker issues go into Linear and requests arrive in a Slack channel. When an author pushes a fix, the push notice names the files that moved. When the checklist is amended, every ledger row was written against the old version. Reviewers re-walk the wrong files or open a blocker issue that already exists, and the ledger stops matching what was actually reviewed.
## Who works in the room
People
- Review desk lead
Pins the checklist version, approves every review before it posts and closes each request
- Checklist owner
Writes and amends the checklist, and confirms when an amendment takes effect
- Pull request authors
Push fixes, send push notices and merge once their reviewers are satisfied
Agents
- FinChecklist reviewer
Walks every changed file against the pinned Notion checklist, writes the four ledger fields per file in Airtable and drafts the GitHub review
GitHub[Notion](https://kylon.io/integrations/notion)Airtable
- RyanBlocker desk
Opens a Linear issue the first time a finding becomes a blocker, and checks that the ledger and the issues stay in step on every re-walk
LinearAirtable
- NovaRequest queue
Takes requests and push notices from Slack in arrival order, briefs Fin on each one, and posts the desk's status after approval
[Slack](https://kylon.io/integrations/slack)Google Drive
The desk works in one Kylon room. Nova takes requests in the order they arrive and briefs Fin on each by opening a thread whose first message names the pull request, the pinned checklist version and any files to re-walk. Fin leads that thread until the review is approved, then hands blocker work to Ryan by mentioning it. Some pull requests in the queue come from the team's own coding agent, such as Codex, which works in the same room; they get the same walk and the same approval as any other.
## One request at a time, in the order they arrive
Requests are worked strictly in arrival order, and each is submitted before the next begins. GitHub, Airtable and Linear change only after the desk lead approves.
```mermaid
flowchart TD
brief["Nova takes each request in arrival
order and briefs Fin"]
walk["Fin walks each changed file against
the pinned checklist"]
okl["Review desk lead approves the
ledger before Airtable is written"]
review["Fin drafts the GitHub review"]
issues["Ryan proposes a Linear issue for
each first-time blocker"]
okb["Review desk lead approves both"]
push([An author's push notice
names the files that moved])
amend["Checklist owner confirms
a checklist amendment"]
rewalk["Fin re-walks only
the named files"]
all["Fin re-walks every file in
every open pull request"]
newb["Ryan proposes an issue only for
a blocker that is new"]
ok2["Review desk lead
approves the changed rows"]
check["Ryan checks the ledger rows
against the blocker issues"]
closed["Review desk lead closes the request"]
brief --> walk --> okl --> review & issues
review & issues --> okb
okb --> push & amend
push --> rewalk
amend --> all
rewalk & all --> newb --> ok2 --> check --> closed
class brief,walk,review,issues,rewalk,all,newb,check agent
class okl,okb,amend,ok2,closed person
class push event
classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712
classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712
classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42
```
| Stage | What happens | Who acts | Who decides |
| --- | --- | --- | --- |
| Walk | Every changed file is checked against every item on the pinned checklist | Fin, from GitHub and the Notion checklist | The desk lead reviews the results |
| Ledger | Four fields are written per file: checklist item, result, note and commit | Fin | The desk lead approves before Airtable is written |
| Review and blockers | The review is posted on the pull request, and a Linear issue opens for each finding that became a blocker for the first time | Fin for the review, Ryan for the issues | The desk lead approves both |
| Push notice | Only the files the notice names are re-walked, and every other row stays as it was | Fin, then Ryan for any new blocker | The desk lead approves the changed rows |
| Checklist amendment | Every file in every open pull request is re-walked against the amended checklist | Fin, with parallel helpers on the largest pull requests | The checklist owner confirms the amendment and the desk lead approves |
| Close | The ledger rows and any blocker issues are checked against each other before the request is closed | Ryan checks and Nova posts the status in Slack | The desk lead closes the request |
Stages of review desk work. Pull request numbers, files and checklist items in this example are illustrative.
## A push notice is narrow, an amendment is not
When an author pushes, the notice lists the files that moved. Fin re-walks exactly those files and leaves every other ledger row untouched, because their reviewed commit has not changed. If a re-walked file now has a blocker it did not have before, Ryan proposes one Linear issue. If the blocker was already there, the existing issue stands and no second one is opened.
A checklist amendment is the opposite case. Every ledger row was written against the old version, so every file in every open pull request is re-walked, including files nobody touched and rows that passed. Fin works through them request by request, still in arrival order, and Ryan compares the new results with the old so that a finding that becomes a blocker for the first time gets its issue and a blocker that already had one does not get another.
## What the checks catch
- A re-walk that strays beyond the files named in the push notice
- Ledger rows left on the old checklist version after an amendment because their files did not change
- A second Linear issue for a blocker that already has one
- A request started before the one ahead of it was submitted
## What stays with people
- Approving every review before it posts on a pull request
- Approving each ledger write and each blocker issue
- Amending the checklist and pinning the new version
- Merging the pull request, which stays with its author and their reviewers
## Integrations in this workflow
Kylon is not a code review tool and it does not replace one. It sits between the code host, the ledger and the tracker the desk already uses, and keeps the review trail across them in one place.
- Airtable
- GitHub
- Google Drive
- Linear
- [Notion](https://kylon.io/integrations/notion)
- [Slack](https://kylon.io/integrations/slack)
- **GitHub** holds the pull requests, their changed files and the posted reviews
- **Notion** keeps the pinned checklist and its version history
- **Airtable** holds the ledger, four fields per file per pull request
- **Linear** carries the blocker issues, one per finding that became a blocker
- **Google Drive** keeps the desk procedure and each checklist amendment memo
- **Slack** is where review requests and push notices arrive and where the desk posts status after approval
## Where to start
Pick one repository and the paths your desk already insists on reading. Pin the checklist in Notion, connect the Airtable base that holds the ledger, and make one rule explicit in the room guidelines: requests are worked in arrival order, and nothing posts to GitHub or Linear until the desk lead approves it.
> “The ledger says which commit each file was reviewed at and against which checklist. That is the whole point of the desk.”
## Set it up with your agent
Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.
Set-up prompt
Set up our pull request review desk in this Room. Take it one step at a time and wait for my OK before you move on.
1. Connect Airtable, GitHub, Google Drive, Linear, Notion and Slack. Tell me which ones still need connecting.
2. Ask me who works this desk: the review desk lead, the checklist owner and the pull request authors. Help me invite them to this Room.
3. Build a Review Desk App with File, Checklist item, Result and Status columns, one row per file per pull request. Fill it from the open pull requests in GitHub and the pinned checklist in Notion.
4. Walk every changed file against every item on the pinned Notion checklist. Write the four ledger fields per file in Airtable and draft the GitHub review. Show me any file that fails a checklist item, and flag any finding that would open a new Linear blocker issue.
5. Draft each GitHub review and each Linear blocker issue for my review. Write nothing to Airtable, post nothing to GitHub and open nothing in Linear until the desk lead approves.
6. Write our rules and who approves each ledger write, review post and blocker issue into this Room's guideline, so every request follows it.
7. After one clean week of requests, offer to turn the queue and status posting into an Automation.
Before you start, ask me for our rules one at a time.
[Get started](https://app.kylon.io/sign-up)
Your first company harness. Where humans and agents run your business together.
[Get started](https://app.kylon.io/sign-up)
## More Use Cases
[View all](https://kylon.io/use-cases)
[
### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move
Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice.
Software & SaaSEngineering operationsEmail operations
](https://kylon.io/use-cases/api-deprecation-migration)[
### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval
A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes.
Software & SaaSIT & security operations
](https://kylon.io/use-cases/backup-restore-verification)