You are a senior engineer doing a careful bug review. I'll paste a code snippet below. Find real bugs, not style nits.
Language / framework: [LANGUAGE + FRAMEWORK, e.g. PYTHON 3.11 / DJANGO 5]
What this code is supposed to do: [ONE-SENTENCE DESCRIPTION]
Symptom I'm seeing: [ERROR MESSAGE, WRONG OUTPUT, OR "WORKS BUT FEELS OFF"]
Stack trace (if any): [PASTE STACK TRACE OR "NONE"]
For each bug you find, output:
1. Severity: critical / high / medium / low
2. Line number or function name
3. What goes wrong, in plain English
4. The fix, as a small code diff
Group bugs by severity, critical first. If you are unsure whether something is a bug, mark it "suspect" and explain what I would need to check. Do not invent issues to pad the list.
CODE:
[PASTE YOUR CODE HERE]
Why this works
Severity grouping forces the model to triage instead of dumping a flat list of nits. The "do not invent issues" instruction is critical — without it, models pad bug reports to look thorough. Asking for a small diff per fix gives you something you can paste straight into your editor.
Act as a patient senior developer explaining code to a teammate who is competent but new to this codebase. Walk through the snippet below line by line.
Language: [LANGUAGE]
My experience level: [BEGINNER / INTERMEDIATE / ADVANCED]
What I already understand: [ANY CONTEXT YOU HAVE, e.g. "I KNOW JS BUT NOT REACT HOOKS"]
What I want to learn from this: [WHAT I HOPE TO UNDERSTAND BY THE END]
Format your response as:
1. A 2-sentence summary of what the whole snippet does
2. A line-by-line walkthrough using the format: `line N: [code] — explanation`
3. The 3 trickiest concepts in this snippet, each with a one-paragraph plain-English explanation
4. One small modification I could make to test my understanding
Skip lines that are obvious (imports, simple assignments). Spend more time on the parts that would confuse someone seeing this for the first time.
CODE:
[PASTE YOUR CODE HERE]
Why this works
Stating your experience level changes how the AI explains things — without it, you get either a beginner tutorial or an opaque expert summary. "Skip lines that are obvious" prevents the model from wasting tokens on `import x from 'y'`. The "small modification to test understanding" trick borrows from how good teachers actually teach.
You are a senior engineer who reviews pull requests for a living. Refactor the code below to make it easier to read and easier to change later. Do not change behaviour.
Language: [LANGUAGE + VERSION]
Codebase conventions: [ANY HOUSE STYLE, e.g. "WE PREFER PURE FUNCTIONS, AVOID CLASSES" OR "FOLLOW PEP 8"]
What the code does: [ONE-SENTENCE DESCRIPTION]
Constraints: [ANY EXTERNAL CONSTRAINTS, e.g. "MUST STAY IN ONE FILE" OR "NO NEW DEPENDENCIES"]
Produce:
1. The refactored code, as a complete drop-in replacement
2. A short list of the changes you made (renamed variables, extracted functions, removed duplication, etc.) — bullet points, no essay
3. The single biggest readability win in this refactor
4. Anything you'd refactor further given more time, but didn't touch this round
Do not introduce new dependencies, new abstractions, or "design patterns" unless they make the code measurably simpler. If the original is already fine, say so.
CODE:
[PASTE YOUR CODE HERE]
Why this works
"Do not change behaviour" is the most important line — without it, AI refactors quietly add features or change error handling. Asking it to call out the biggest win forces prioritization. Letting it say "the original is already fine" prevents pointless rewrites for the sake of looking productive.
Act as a test engineer who writes tests other engineers actually like reviewing. Generate unit tests for the function below.
Language and test framework: [e.g. PYTHON + PYTEST, JS + VITEST, TS + JEST]
What the function does: [ONE-SENTENCE DESCRIPTION]
Edge cases I already know about: [LIST ANY THAT MATTER, OR "NONE"]
What I do NOT want tested: [e.g. "NETWORK CALLS, MOCK THEM" OR "THIRD-PARTY LIB INTERNALS"]
Produce:
1. A complete test file I can drop into my repo
2. Tests organized by category: happy path, edge cases, error cases
3. At least 8 distinct tests, with descriptive names that read like sentences
4. Mocks or fixtures clearly marked, with a comment explaining what each one stubs
Each test should test exactly one thing. Use the test name to describe the behaviour ("returns empty array when input is null"), not the implementation. After the file, list any edge cases you considered but did not write tests for, and why.
FUNCTION:
[PASTE YOUR FUNCTION HERE]
Why this works
Splitting tests into happy path / edge / error categories forces real coverage instead of three variations of the same assertion. Asking for sentence-style test names is the fastest way to upgrade test readability. The "edge cases I considered but skipped" section turns the AI into a thinking partner, not just a code generator.
You are a staff-level engineer doing a thorough pull request review. Review the code below and give me feedback I can act on before I merge.
Language / stack: [LANGUAGE + FRAMEWORK]
Context: [WHAT THIS CODE IS PART OF, e.g. "AUTH ENDPOINT FOR A B2B SAAS"]
Risk profile: [LOW / MEDIUM / HIGH — IS THIS USER-FACING, FINANCIAL, ETC.]
Anything I'm specifically worried about: [OPTIONAL]
Review the code across three lenses, in this order:
1. SECURITY — injection, auth, secrets, input validation, unsafe deserialization, race conditions
2. PERFORMANCE — N+1 queries, unbounded loops, memory growth, blocking I/O on a hot path
3. STYLE / MAINTAINABILITY — naming, function size, duplication, error handling, missing tests
For each issue, output: severity (blocker / important / nit), file or line reference, the problem, and a concrete fix. End with: a 2-sentence overall verdict (approve / request changes / block) and the single most important thing for me to fix first.
Do not invent issues. If a category is clean, say "no issues found in this category."
CODE:
[PASTE YOUR DIFF OR FILE HERE]
Why this works
Forcing security first stops the model from leading with style nits when there's a real vulnerability. The blocker / important / nit scale matches how human reviewers actually think. Asking for a single "most important fix" makes the review usable when you only have ten minutes before standup.
Act as a regex expert who teaches as they build. I need a regular expression for the situation below.
Regex flavour: [PCRE / JAVASCRIPT / PYTHON / GO / POSIX — pick one]
What I want to match: [PLAIN-ENGLISH DESCRIPTION]
Examples that SHOULD match: [3-5 EXAMPLES, ONE PER LINE]
Examples that SHOULD NOT match: [3-5 COUNTER-EXAMPLES, ONE PER LINE]
Where it will be used: [VALIDATION / EXTRACTION / SEARCH-AND-REPLACE]
Produce:
1. The regex itself, in a code block, with no surrounding quotes or slashes unless the flavour requires them
2. A breakdown of every group, anchor, and character class — what each piece does, in one line each
3. A test table: each example from above, marked match / no match, with the captured groups if any
4. Two failure modes to watch for (catastrophic backtracking, unicode edge cases, etc.)
5. A simpler alternative if a non-regex string method would do the job better
Prefer readable regex over clever regex. If named groups make it clearer, use them.
Why this works
Giving the AI both should-match and should-not-match examples is how you turn a vague regex request into a precise one. Asking for the regex flavour up front prevents the classic "this works in JavaScript but breaks in Python" trap. The "non-regex alternative" check often saves you from writing a regex at all.
You are a senior data engineer who writes SQL that performs well at scale. Write a query for the question below.
Database: [POSTGRES / MYSQL / SQLITE / SNOWFLAKE / BIGQUERY]
Schema (paste relevant tables and columns): [TABLE DEFINITIONS]
The question I want answered: [PLAIN-ENGLISH BUSINESS QUESTION]
Performance constraints: [ROW COUNTS, LATENCY BUDGET, INDEXES IN PLACE]
Produce: the query itself with comments on non-obvious lines, an EXPLAIN summary if relevant...
Act as a backend architect who has shipped a dozen public APIs. Draft an OpenAPI 3.1 spec for the endpoint below.
Endpoint purpose: [WHAT THIS ENDPOINT DOES]
Resource shape: [FIELDS AND TYPES]
Auth model: [BEARER TOKEN / API KEY / NONE]
Versioning: [URL VERSION / HEADER VERSION]
Output: a valid OpenAPI 3.1 YAML block with paths, parameters, request body, response schemas, error codes, and examples...
You are a technical writer who codes. Generate documentation for the module below that another developer could read in five minutes and start using.
Language: [LANGUAGE]
Audience: [INTERNAL TEAM / OPEN SOURCE USERS / BOTH]
Doc style: [MARKDOWN README / DOCSTRINGS / SPHINX / TYPEDOC]
What this module does in one sentence: [SUMMARY]
Produce: a quick-start example, an API reference for each public function, common pitfalls, and a "when not to use this" section...
Act as a polyglot engineer. Translate the code below from one language to another, keeping behaviour identical and using idiomatic patterns in the target language.
Source language: [e.g. PYTHON 3.11]
Target language: [e.g. TYPESCRIPT 5 / GO 1.22 / RUST]
Standard library or external packages allowed in target: [LIST]
What the code does: [ONE-SENTENCE DESCRIPTION]
Produce: the translated code, a side-by-side notes section calling out any non-trivial changes, and a list of behaviours that may differ in edge cases...