From a sprawling PR to an informed decision.
Open the pull request you need to review.
Paste a GitHub pull request URL, or pick one from your projects. Airlock finds the local repository, or helps you clone it, and fetches the branch. Inspect the commits and files while the agent prepares a reading plan.
Know what to read. And why.
The agent reads the full change and surrounding source, then groups references into ordered sections with a reason to read each. Open the code, pulled directly from git, and mark sections read as you go.
Ask a question. Check the cited code.
Ask the agent about what you are reading; its answers cite files and lines you can inspect. It also checks statements in the PR description against the code. Questions about why the author made a choice stay for the author to answer.
Build your review from what you find.
Save an answer after checking it, write your own note, or add a question for the author. Each goes into your review under its file or section. You can edit or remove it later.
Your review, ready to share.
Edit your saved notes, answers, and author questions together. Preview the finished review, copy it as Markdown, and paste it into GitHub. You choose every entry and when to post it.
- Follow the plan. The agent reads the full change and surrounding source, then groups references into ordered sections with a reason to read each. Open the code, pulled directly from git, and mark sections read as you go.
- Check the evidence. Ask the agent about what you are reading; its answers cite files and lines you can inspect. It also checks statements in the PR description against the code. Questions about why the author made a choice stay for the author to answer.
- Choose what to keep. Save an answer after checking it, write your own note, or add a question for the author. Each goes into your review under its file or section. You can edit or remove it later.
- Export your review. Edit your saved notes, answers, and author questions together. Preview the finished review, copy it as Markdown, and paste it into GitHub. You choose every entry and when to post it.
- 01The payment requestFollow a checkout from Pay to the payment provider.Read
- 02Duplicate protectionCheck how repeat requests reuse the same payment key.Read
- 03Timeouts & testsInspect the test for a lost payment response.Read
- 01The storage interfaceRead what a session store is now required to do.Read
- 02The Postgres implementationCheck the existing queries against the new methods.Read
- 03Callers and fixturesInspect what the tests substitute for the real store.Read
- 01What v7 removedRead the calls that no longer exist in the new client.Read
- 02The call sitesCheck each replacement against what it replaced.Read
- 03Webhook signaturesInspect how an incoming webhook is verified now.Read
“What if payment succeeds but the response never arrives?”
The retry reuses the original payment key. The timeout test checks that only one charge is created.
“What happens to sessions already in flight when this ships?”
The Postgres implementation keeps the existing table and column names, so a row written before the deploy still resolves through the new interface.
“Does v7 change how webhook signatures are verified?”
v7 moves verification onto the client and drops the standalone helper. The call site passes the raw body, which the old helper also required.
- An answer you checked
After a timeout, retries reuse the original payment key.
Added - A note in your words
Please also test two Pay clicks arriving together.
Added - A question for the author
How long should a customer be able to retry a payment?
Added
- An answer you checked
The Postgres store keeps the existing table, so sessions in flight survive the deploy.
Added - A note in your words
Worth a test that writes a row in the old shape and reads it through the interface.
Added - A question for the author
Is a second implementation planned, or is the interface here for the tests?
Added
- An answer you checked
v7 verifies webhooks on the client, and the raw body is still what gets signed.
Added - A note in your words
The retry backoff takes new defaults in v7 — worth saying so in the description.
Added - A question for the author
Was a compatibility shim considered, or is a diff this size deliberate?
Added
After a timeout, retries reuse the original payment key.
Please also test two Pay clicks arriving together.
How long should a customer be able to retry a payment?
The Postgres store keeps the existing table, so sessions in flight survive the deploy.
Worth a test that writes a row in the old shape and reads it through the interface.
Is a second implementation planned, or is the interface here for the tests?
v7 verifies webhooks on the client, and the raw body is still what gets signed.
The retry backoff takes new defaults in v7 — worth saying so in the description.
Was a compatibility shim considered, or is a diff this size deliberate?