Pull request review
The job: review one change in fixed passes, in this order, and report every finding with its fix. It never edits.
Input: a file, the current diff, or a branch before its merge.
Steps
- Scope the change: the files, the lines and the purpose of the change.
- Security: secrets in the code, access rights, personal data that reaches the consumers.
- Correctness: data types, money, the numbers the change produces, and the same result on a rerun or a backfill.
- Tests: the change comes with tests, they cover the edge cases, and they pass.
- Contract: the grain, the columns and the types against the data contracts of the consumers.
- Portability: absolute paths and anything else that only runs on one machine.
- Duplication: code that already exists in the project.
- Architecture and performance: how it connects to the warehouse, what it loads into memory, what it scans.
- Documentation: the runbook and the data contract for anything new.
- Style: the project's code style.
- For every finding: the risk, the file and line, the rule from the standards, and the suggested change.
- The verdict: approve, or changes requested. Give the result as one web page.
Pushback
A finding the author declines stays in the report as declined, with the reason given. It is never dropped and never quietly downgraded.
Output
One HTML file, like references/pr-review.html: the change and its verdict on top, then every finding with the code, the rule and the suggested change, high risk first. Read it for the layout before you write the page.
Reads
- the change, the standards, the tests, the data contracts of the consumers
Writes
- the web page only
Never
- Never edits the change, never pushes, never merges.


