Pre-merge risk review

Review a diff for bugs that pass CI but break production, ranked with file/line evidence and missing tests.

Run it as a prompt

Paste this into any AI agent, or fetch it: curl -s https://uplift.page/api/v1/prompts/pre-merge-risk-review/raw

prompt.md

# Pre-merge risk review

Review this change the way the person on call next week would: hunt for bugs that pass CI but break production.

## Input
- What the change does and why: [CHANGE SUMMARY]
- Diff, PR, or branch to compare against the base branch: [DIFF OR BRANCH]

If you can read the repository, read the changed files in full plus their direct callers, not only the diff hunks.

## Check, in this order
1. Trust boundaries: untrusted input reaching queries, shell commands, file paths, redirects, HTML, or permission checks.
2. Data integrity: invariants that can break, multi-step writes without a transaction, migrations that lock or rewrite large tables, irreversible changes.
3. Concurrency: races, double submits, retries without idempotency keys, check-then-act gaps.
4. Failure handling: swallowed errors, missing timeouts, retries that amplify an outage, behaviour when a dependency is down.
5. Performance: N+1 queries, unbounded loops or result sets, new work on hot paths, cache invalidation.
6. Compatibility: API or schema changes that break existing clients, jobs already queued, or a rollback.
7. Tests: what matters most and is untested.

## Rules
- Every finding cites a file and line (or function) and states the concrete failure: the input, the sequence, the result.
- Rank by severity times likelihood. At most 10 findings. No style nits.
- Write "nothing found" for a category rather than inventing an issue.
- Do not edit code; this is a review.
- Where possible, give a command or request that confirms each finding (a curl, a query, a test name).

## Output
1. Verdict: ship / ship after fixes / do not ship, with one sentence why.
2. Findings table: severity (critical/high/medium/low), location, failure mode, how to reproduce, suggested fix.
3. The 5 tests most worth adding, each as a name plus the assertion.

The full prompt

Review this change the way the person on call next week would: hunt for bugs that pass CI but break production.

Input

What the change does and why: [CHANGE SUMMARY]
Diff, PR, or branch to compare against the base branch: [DIFF OR BRANCH]

If you can read the repository, read the changed files in full plus their direct callers, not only the diff hunks.

Check, in this order

Trust boundaries: untrusted input reaching queries, shell commands, file paths, redirects, HTML, or permission checks.
Data integrity: invariants that can break, multi-step writes without a transaction, migrations that lock or rewrite large tables, irreversible changes.
Concurrency: races, double submits, retries without idempotency keys, check-then-act gaps.
Failure handling: swallowed errors, missing timeouts, retries that amplify an outage, behaviour when a dependency is down.
Performance: N+1 queries, unbounded loops or result sets, new work on hot paths, cache invalidation.
Compatibility: API or schema changes that break existing clients, jobs already queued, or a rollback.
Tests: what matters most and is untested.

Rules

Every finding cites a file and line (or function) and states the concrete failure: the input, the sequence, the result.
Rank by severity times likelihood. At most 10 findings. No style nits.
Write "nothing found" for a category rather than inventing an issue.
Do not edit code; this is a review.
Where possible, give a command or request that confirms each finding (a curl, a query, a test name).

Output

Verdict: ship / ship after fixes / do not ship, with one sentence why.
Findings table: severity (critical/high/medium/low), location, failure mode, how to reproduce, suggested fix.
The 5 tests most worth adding, each as a name plus the assertion.

Served from the uplift.page library and refreshed within 5 minutes of every update.