How to Run a Code Review Skill on a Pull Request

Anyone who owns a pull request can run a code review skill on it in 15 minutes: paste the diff, demand findings with a file and a line, tag severity, and stop before the style essay. Use ChatGPT, Claude, or Gemini on code you are allowed to share, or a local model when you are not.

A review without a line is a blog post.

This is a skill with a stop, not a “look at this PR” chat. If you need the loop pattern, read what a skill prompt actually is, then lock the law below.

Review the diff, not the author’s soul

State the law before you paste. If you paste first, the model starts rewriting and retrofits a rationale.

1. Paste the diff and the failing proof, nothing else

The input is the pull request diff plus any test output or type-check you already have. Not the whole tree. Not “and the rest of the service for context.”

Instruct: “You may comment only on hunks in this diff. If you need a file that is not here, write NEED and name the file. Do not invent its contents.”

NEED is a request to you, not a license to invent a file.

If the diff cannot leave your laptop, do not paste it into a hosted chat. Run the same law on a local model. The Qwen 3.8 27B local coding-agent note is the privacy pattern: keep the patch on your box, still demand file plus line, still treat invented files as failure.

2. Force the finding shape

One finding, four fields:

• File and line, from the diff.
• Severity: BLOCK, RISK, or NIT.
• What the hunk does, in one sentence, in the code’s words.
• Why it matters, in one sentence, without a lecture.

“If you cannot point at a line, you do not have a finding. No ‘consider also.’ No architecture essay. Maximum eight findings. Extra items go under PARKED and get no prose.”

BLOCK is “this should not merge as written.” RISK is “this can break a case you named.” NIT is taste. If the model tags taste as BLOCK, send it back.

3. Ban the fake bug

Models love a security novel. They will invent an injection on a line that only formats a string you already control.

Tell Claude, ChatGPT, or Gemini: “Do not report a vulnerability unless the diff shows the data flow. If you are not sure, write UNVERIFIED and stop. Do not write a proof of concept. Do not write exploit steps.”

UNVERIFIED is a yellow flag for you to open the file. It is not a finding.

Confirm BLOCKs by opening the line. If the line is not doing what the model said, restart with that finding as a counterexample.

4. Tests and types stay yours

Ask: “Which findings are contradicted by the test output I pasted? Drop those. Do not invent tests. Do not claim coverage I did not show.”

If you want tooling around the loop, the Promptcrates tools page is where you save the review law so the next PR does not start from “any thoughts.”

5. You write the review comment

Read the eight or fewer findings out loud. Keep the BLOCKs you can defend. Drop the rest.

Write the comment in your words. Send: “Do not polish this into a manifesto. The review is the list.”

Then stop.

Reuse the law, not last week’s findings. More loops live in the Promptcrates guides.

Reusable skill card

Trigger: You are about to paste a pull request into ChatGPT, Claude, or Gemini and ask if it looks okay.

Input: The diff, any test or type output you already have, the four-field finding shape, a cap of eight, and a ban on invented files.

Output: Up to eight findings with file, line, severity, and two sentences. NEED if a file is missing. UNVERIFIED instead of a guessed bug. PARKED nits.

Stop: After you verify BLOCKs on the line and write the comment. No rewrite. No exploit sketch. No style manifesto.

Takeaways

• Diff plus proof you already have. Not the whole repo.
• File and line or it is not a finding.
• BLOCK, RISK, NIT. Taste is not a blocker.
• UNVERIFIED is not a vulnerability report. You open the line.
• Save the review law as a skill. Private diffs stay local.