You are the most thorough reviewer on my team — kind, but nothing gets past you.
Here's my diff:
{{paste your diff or changed files}}
Context: {{what this change is supposed to do}}
Review it:
1. CORRECTNESS — bugs, edge cases, race conditions. Rank by severity; say "solid" if it's solid.
2. NAMING & CLARITY — the 3 spots a stranger would misread first.
3. THE QUESTION — what will a reviewer inevitably ask about this diff? Draft my answer.
4. TESTS — the one test that's missing and would catch a real regression.
Skip style nitpicks a linter would catch.
You are a senior engineer doing a patient code review.
Here's my error:
{{paste the full error message}}
Here's the relevant code:
{{paste the smallest chunk that reproduces it}}
Respond in exactly this order:
1. ROOT CAUSE — one sentence, no hedging.
2. THE MINIMAL FIX — smallest possible diff, shown as before/after.
3. THE MISCONCEPTION — what I likely misunderstood for this bug to exist, explained like I'm smart but new to this corner of the language.
4. THE SMELL TEST — one thing to check elsewhere in my codebase where I've probably made the same mistake.
Do not refactor unrelated code. Do not add features.
I'm stuck in git. Help me fix it without losing work.
What happened / what I want: {{describe — wrong branch, bad commit, need to undo, merge conflict, detached head...}}
Output of git status (and git log if relevant):
{{paste}}
Give me: 1) WHAT STATE I'm actually in, plainly. 2) THE SAFE FIX — exact commands in order, with what each does and why. Prefer non-destructive options; clearly flag anything that discards work before I run it. 3) HOW TO VERIFY it worked. 4) THE HABIT that prevents this next time. Assume I'll paste your commands literally — don't hand-wave.
Help me build a regular expression.
What I want to match (with examples that SHOULD and SHOULDN'T match):
{{describe + examples}}
Language/flavor: {{JS, Python, PCRE...}}
Give me: 1) THE REGEX. 2) A PLAIN-ENGLISH breakdown, piece by piece, so I understand not just copy. 3) TEST CASES — run my examples against it and show pass/fail; add tricky ones I didn't think of. 4) THE GOTCHAS — where this will over- or under-match in the real world (unicode, edge whitespace, greedy vs lazy). 5) When regex is the WRONG tool here and I should parse instead.
Be my rubber duck. I'm about to build something — poke holes before I waste a day.
What I'm building & why: {{the goal}}
My planned approach: {{how you intend to do it}}
Constraints: {{stack, deadline, scale}}
Respond: 1) PLAY IT BACK — restate my plan so I know you understood. 2) THE FLAWS — where this breaks, gets slow, or gets painful to maintain. Rank by likelihood. 3) THE SIMPLER PATH — is there a materially easier approach I'm overcomplicating past? 4) THE EDGE CASES I haven't mentioned. 5) THE FIRST STEP if the plan holds. Push back honestly — don't just validate me.
Review my code's comments — add what's missing, cut what's noise.
My code:
{{paste it}}
Do this: 1) ADD comments only where they earn their place — the WHY behind a non-obvious choice, a constraint, a gotcha, a 'do not change this because…'. 2) FLAG comments that just restate the code ('// increment i') and should be deleted. 3) SUGGEST where a better name would remove the need for a comment entirely. 4) If any function needs a short doc-comment (purpose, params, gotchas), write it. Keep my style; don't over-comment.
You are a database engineer reviewing my SQL.
The query:
{{paste it}}
Table sizes (rough): {{e.g. users 100k, events 10M — or "unknown"}}
Explain:
1. IN ENGLISH — what this query returns, one sentence a PM would understand.
2. THE EXECUTION STORY — walk through what the database actually does, in order, like a narrated field trip.
3. THE SLOW PART — which step hurts at scale and at roughly what row count it starts hurting.
4. THE FIX — index, rewrite, or both. Show the exact CREATE INDEX / rewritten query, and the trade-off it introduces.
5. THE GOTCHA — one way this query silently returns wrong data (NULLs, duplicates from joins, timezone).
If the query is actually fine, say so — don't invent problems.
You are a QA engineer with a gift for breaking things.
My function:
{{paste it}}
What it's supposed to do: {{one sentence}}
Attack it:
1. EDGE CASES — list every input class that could break it: empty, null, zero, negative, enormous, unicode, wrong type, boundary values. Mark which ones my code currently survives (read it carefully) vs. fails.
2. THE WEIRD ONE — the input I'd never think of that real users will absolutely send.
3. CONCURRENCY/STATE — if called twice at once or out of order, what breaks?
4. WRITE THE TESTS — for the 5 highest-risk cases, in {{test framework}}, with names that describe the behavior ("returns_empty_list_when...").
Rank findings by "will actually happen in production" — not by theoretical purity.
You are a senior engineer giving me a guided tour of code I've never seen.
Here's the code (structure + key files):
{{paste directory tree and/or main files}}
What I need to do here: {{the task that brought me}}
Orient me:
1. THE 30-SECOND MAP — what kind of app/library this is and its architectural shape (MVC? pipeline? event-driven?).
2. ENTRY POINTS — where execution starts, where requests/inputs come in.
3. THE MONEY PATH — trace the single most important flow end to end, file by file.
4. FOR MY TASK — which files I'll touch, in what order, and which files LOOK relevant but aren't (say why).
5. THE LANDMINES — anything with global state, hidden side effects, or "do not touch without tests".
End with: the first small, safe change I could make to test my understanding.
Help me design a clean API before I lock it in.
What it does & who calls it: {{internal service? public? a library?}}
The main operations: {{list what callers need to do}}
Constraints: {{stack, auth, versioning needs}}
Design: 1) THE ENDPOINTS/SIGNATURES — named consistently, predictable, following the conventions of my ecosystem. 2) INPUTS & OUTPUTS — shapes, required vs optional, sensible defaults. 3) ERRORS — how failures are reported so callers can handle them. 4) THE FUTURE-PROOFING — what's likely to change, and how to design so v2 doesn't break v1 callers. 5) THE SMELL CHECK — anything here that'll be painful to live with. Prioritize caller experience over implementation convenience.
You are an open-source maintainer who knows a README is a landing page.
My project: {{what it does, paste code structure or description}}
Who lands here: {{beginners? teammates? potential users?}}
Write the README:
1. ONE-LINER — what it does + who it's for, no jargon, under 15 words.
2. THE BEFORE/AFTER — the pain without it, the result with it (code or bullets).
3. QUICKSTART — the genuinely minimal path to first success, tested-looking, with expected output shown.
4. ONE REAL EXAMPLE — the most common use case, complete and copy-pasteable.
5. HONEST LIMITS — what it doesn't do / when not to use it.
6. Contributing + license, two lines.
No badges wall, no table of contents for a 2-screen file, no "blazingly fast".
Help me choose between technical options without hype.
The decision: {{e.g. Postgres vs Mongo, Next vs Remix, this library vs that}}
My actual constraints: {{team skills, scale, timeline, existing stack, budget}}
What matters most: {{speed to ship? scale? maintainability? hiring?}}
Give me: 1) A short honest comparison against MY constraints — not a generic feature table. 2) THE DECIDING FACTOR — the one or two things that should actually drive this for me. 3) YOUR PICK and why, plus the strongest case for the runner-up. 4) THE REVERSIBILITY — how hard is this to change later? (Cheap-to-reverse decisions deserve less agonizing.) 5) The trap people fall into with this choice.
I already code. Get me productive in {{new language}} fast.
Languages I know well: {{list}}
What I need to build in it: {{context}}
Give me: 1) THE MAP — what transfers directly from what I know, so I don't relearn basics. 2) THE GOTCHAS — where my instincts from {{known language}} will actively mislead me (memory, types, concurrency, error handling). 3) THE IDIOMS — the 5-6 things that make code look native here vs. translated-from-my-old-language. 4) A TINY PROJECT that forces me through the core concepts, with what to notice. 5) The one tooling/setup thing that trips up newcomers. Skip 'what is a variable.'
Help me name things in my code better.
The names I'm unsure about (with a line on what each does):
{{paste variables / functions / files}}
Language & conventions: {{context}}
Do this: 1) RENAME each — clearer, following my language's conventions (camelCase/snake, etc.), revealing intent not implementation. 2) THE WHY for each change in a few words. 3) THE SMELLS — names that hint at a deeper problem (a function named with 'and' is doing two things; a boolean named badly inverts logic). 4) THE PRINCIPLE — the one naming rule I'm breaking most, so I fix it everywhere. Good names remove the need for comments.
Help me decide whether to refactor this now.
The code that bothers me:
{{paste it}}
Context: {{how often it changes, how central it is, deadline pressure}}
Judge honestly: 1) IS IT ACTUALLY BAD, or just unfamiliar/ugly-but-fine? Be real. 2) THE COST of leaving it — bugs, slowdowns, onboarding pain — weighted by how often this code is touched. 3) THE COST of refactoring now — time, risk of new bugs, opportunity cost. 4) THE VERDICT — refactor now, refactor-when-you-next-touch-it, or leave it alone. 5) If refactoring: the smallest safe first step and the test to add first. Don't tell me to gold-plate code nobody touches.