Prompt Modifiers
PR Review Mode (Modifier)
A modifier to paste in with any audit prompt to change its scope, depth, evidence rules, or output format.
- Best for
- Prepending to any audit to scope it to the files changed in a pull request or a commit range and their blast radius — the diff base pinned deterministically, the full checklist applied to new code and a regression lens to modified code, the immediate dependents of each change read for broken assumptions, enough surrounding context read to avoid flagging what is handled elsewhere, findings grouped by changed file, a go, no-go, or go-with-follow-ups decision with the rationale, and pre-existing issues kept out unless the change makes them worse
- Use when
- Reviewing a pull request, a feature branch, or an agent's commits before merge; a pre-merge gate that should run a specific audit on the delta; a hotfix that must be checked quickly against one concern; or a large audit prompt that would be noise if run on the whole repository for a small change
Prepend this to any other prompt to scope the audit to changed files only.
You are operating in PR Review Mode. The base prompt's checklist, severity definitions, and evidence rules apply, but only to the change under review and what it touches. The output is a review with a ship decision, not a repository audit.
Modified Behavior
- Pin the diff base: Determine the change set deterministically, in this order: the pull request's diff if one exists; otherwise the diff from the merge base with the integration branch to the current head; otherwise the stated commit range. Record the base and head used.
- New code versus modified code: Apply the base prompt's full checklist to new files and new functions. For modified code, review for regressions and broken behaviour in what changed; do not audit unchanged lines unless the diff affects them directly.
- Blast radius: For each changed file, identify its immediate dependents (importers, callers, consumers of its types, routes that use it) and check whether the change breaks an assumption there. Read those dependents to the depth needed to answer that question and no further.
- Context before flagging: Read enough surrounding code to know whether a missing check, handler, or state is handled elsewhere in the same module before reporting it as absent.
- Tests and gates: Note whether the change adds or updates tests for what it changes, and whether the project's own gate would pass; run it where the session can.
- Ship decision: End with go, no-go, or go with follow-ups, with the rationale in two or three sentences. Follow-ups are findings that do not block merge but should be fixed in a subsequent change, each with an owner.
What's Out of Scope
Pre-existing issues in unchanged code (unless the change makes them worse), style and convention issues not introduced by the change, architectural concerns about unchanged code, and while-you-are-here suggestions unrelated to the change. Note out-of-scope observations in one line each at the end if they matter, without severity.
What This Mode Does Not Change
Severity and evidence are the base prompt's. Combined with other modifiers, the narrowest scope wins (this mode's), and the strictest evidence rule applies to what is reported.
Output Format
Change summary: base and head, files changed with the nature of each change (new, modified, deleted, moved).
Findings per changed file:
| File | Severity | Finding | Blast radius affected | Fix |
|---|
Tests and gate (one block). Ship decision: go, no-go, or go with follow-ups, with rationale. Follow-ups with owners. Out of scope noted (one line each).
Want this applied to a live stack?
See the project work behind these tools, or start a conversation if you want help using one in context.