Strict code review that ignores style
codingReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
Review names before they become load-bearing
Checks function, table, and endpoint names against what they actually do.
When to use it
A new module, table, or endpoint is about to be written and the names are already in place.
The prompt
Copy into your assistant
Review these names against what the code actually does.
For each name, answer three questions:
1. Does it describe what the thing does, or how it was implemented?
2. Would it still be true if the behaviour changed in an obvious way?
3. Would two other engineers agree on what it means without reading the code?
Then propose a replacement only where a name fails a question, and say why the new one is better.
Rules:
- Do not propose renaming more than a third of the list; that is a rewrite, not a review.
- No naming-convention opinions. Only meaning.
- If a name is fine, say 'fine' and move on.
Names and what they do:
<list>What to change
Include what the thing does in one line — otherwise the model is reviewing the names against themselves.
Why it works
Question 2 is the useful filter: names that go stale are the ones written against an implementation rather than a purpose.
More coding prompts
- Security review of a diffLooks for injection, authorization gaps, and secret leakage — and refuses to comment on anything else.
- Log triage: from noise to three hypothesesGroups a messy log into failure signatures and ranks hypotheses before anyone touches code.
- Accessibility audit of a componentChecks markup against the failures screen readers actually hit, not a checklist of rules.
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