Strict code review that ignores style
codingReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
Explain unfamiliar code before touching it
Produces a map of responsibilities, data flow, and the parts that look dangerous to change.
When to use it
First contact with a module you have to change this week.
The prompt
Copy into your assistant
Explain the code below as if onboarding a new engineer who must change it safely.
Produce, in this order:
1. What problem it solves, in two sentences, with no jargon.
2. The data that flows through it: where it enters, how it is transformed, where it leaves.
3. The three things most likely to break if changed, and why.
4. Any place where the code disagrees with its own comments or names.
Rules:
- No suggestions. This is a reading exercise.
- If something is genuinely unclear, say "unclear from the code shown" rather than guessing.
- Quote line numbers for every claim.
Code:
<code>What to change
Ask for line numbers on every claim — it prevents the model from describing an architecture the file does not actually have.
Why it works
Explaining before editing is the cheapest way to avoid a confident rewrite of code nobody understood. The 'disagrees with its own names' item catches the traps.
More coding prompts
- Question to SQL, with the assumptions spelled outTurns a business question into a query plus the schema assumptions it made.
- Review an API design before you build itPressure-tests an endpoint spec for naming, pagination, errors, and the version you will regret in a year.
- A migration plan with a rollback you can actually runPlans a brownfield migration in steps small enough to revert, and names the point of no return.
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