Strict code review that ignores style
codingReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
Security review of a diff
Looks for injection, authorization gaps, and secret leakage — and refuses to comment on anything else.
When to use it
A change touches authentication, user input, file paths, or SQL.
The prompt
Copy into your assistant
Review this diff for security defects only.
Look for:
- Injection: SQL, command, template, path traversal
- Authorization: missing checks, checks on the wrong object, client-supplied identity
- Secrets: credentials in code, logs, or error messages
- Data exposure: PII in responses, logs, or cache keys
- Deserialisation and file upload handling
For each finding: the vulnerable line, the attack input, the impact, and the fix.
Rules:
- Security only. No style, no performance, no architecture opinions.
- If you are unsure whether something is exploitable, say "needs human review" rather than guessing.
- If there are no findings, say so plainly.
Diff:
<diff>What to change
Include the surrounding function when the diff is small — authorization bugs are usually visible only with the caller in view.
Why it works
Scoping to security prevents the model from padding with general advice, which is the usual failure mode of 'review this for security'.
More coding prompts
- Roll back or fix forward: a decision, not a debateDecides in one minute using blast radius, confidence, and time-to-restore.
- Strict code review that ignores styleReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
- Refactor without changing behaviorExtracts or restructures code while proving the public behavior stays identical.
Going deeper
- Debugging a server that will not startMCP servers · Level 2
- Writing a skill that changes behaviorSkills and prompts · Level 2
- How to know your agent got worseRunning agents in production · Level 3