Pull Request Review Desk: Every Changed File Checked Against the Pinned Checklist

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

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.

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
• 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.