Code Review Request
Ask an assistant to review a code change for correctness, readability, edge cases, and security concerns.
Prompt template
You are reviewing a {{language}} code change. Review the following code for correctness, readability, performance, and security. List issues by severity (critical, moderate, minor), and suggest concrete fixes. Do not rewrite the whole file unless asked.
Context: {{context}}
Code:
{{code}}
Placeholders
{{language}} — Language- Programming language of the snippet. Example: TypeScript
{{context}} — Context- What the code does and where it runs. Example: Express route handler that updates a user's email address.
{{code}} — Code- The code to review, pasted as-is. Example: app.post('/user/email', async (req, res) => {
const { email } = req.body;
await db.users.update({ email });
res.sendStatus(200);
});
Example input
language: TypeScript · context: Express route handler that updates a user's email address · code: the handler above (no validation, no auth check, no error handling).
Filled-in example
You are reviewing a TypeScript code change. Review the following code for correctness, readability, performance, and security. List issues by severity (critical, moderate, minor), and suggest concrete fixes. Do not rewrite the whole file unless asked.
Context: Express route handler that updates a user's email address.
Code:
app.post('/user/email', async (req, res) => {
const { email } = req.body;
await db.users.update({ email });
res.sendStatus(200);
});
Expected output format
A severity-grouped list (critical / moderate / minor), each item naming the specific line or pattern and a concrete fix — not a full rewritten file.
Customization tips
- Add "focus only on security" or "focus only on performance" to narrow the review.
- Paste a diff instead of a full file when you only changed a few lines.
- Ask for a one-line summary first if you want a quick verdict before the details.
Limitations
- The assistant cannot run your code or test suite, so it can miss runtime-only bugs.
- Without full repository context, suggestions about naming or architecture may not fit your codebase conventions.
Safety notes
- Redact secrets, API keys, and customer data from any code you paste.
- Treat every suggestion as a draft for human review, not an auto-mergeable patch.
Generate Unit Tests
Draft unit tests for a function, including edge cases you might not think of.
Prompt template
Write unit tests for the following {{language}} function using {{test_framework}}. Cover typical inputs, boundary conditions, and error cases. Explain any assumption you make about behavior that isn't obvious from the code.
Function:
{{code}}
Placeholders
{{language}} — Language- Programming language of the function. Example: Python
{{test_framework}} — Test framework- Testing library or framework to target. Example: pytest
{{code}} — Code- The function to test. Example: def split_full_name(full_name: str) -> tuple[str, str]:
parts = full_name.strip().split(' ', 1)
return parts[0], parts[1] if len(parts) > 1 else ''
Example input
language: Python · test_framework: pytest · code: the split_full_name function above.
Filled-in example
Write unit tests for the following Python function using pytest. Cover typical inputs, boundary conditions, and error cases. Explain any assumption you make about behavior that isn't obvious from the code.
Function:
def split_full_name(full_name: str) -> tuple[str, str]:
parts = full_name.strip().split(' ', 1)
return parts[0], parts[1] if len(parts) > 1 else ''
Expected output format
A runnable test file (or set of test functions) in the requested framework, plus a short list of the assumptions made about edge cases.
Customization tips
- Ask for property-based tests if your framework supports them (e.g. Hypothesis, fast-check).
- Request tests for a specific bug you just fixed, so the new test guards against regressions.
- Ask the assistant to flag inputs it could not infer expected behavior for.
Limitations
- Generated tests reflect the assistant's guess at intended behavior — verify expectations against your actual spec.
- Tests are not executed by the assistant; run them yourself before trusting the results.
Safety notes
- Do not paste production data, credentials, or personally identifiable information as sample inputs.
- Review generated tests for false positives (tests that always pass regardless of correctness).
Explain an Error or Stack Trace
Get a plain-language explanation of an error message and a short list of likely causes.
Prompt template
Explain this {{language}} error in plain language, then list the most likely causes ordered by probability, and one concrete way to verify each cause.
Environment: {{environment}}
Error or stack trace:
{{error}}
Placeholders
{{language}} — Language- Language or runtime that produced the error. Example: Node.js
{{environment}} — Environment- Where the error happened. Example: Local dev, Node 22, Next.js 16 app route.
{{error}} — Error / stack trace- The full error text or stack trace. Example: TypeError: Cannot read properties of undefined (reading 'id')
at getUser (src/lib/users.ts:12:18)
Example input
language: Node.js · environment: Next.js 16 app route, Node 22 · error: TypeError reading 'id' on undefined in getUser.
Filled-in example
Explain this Node.js error in plain language, then list the most likely causes ordered by probability, and one concrete way to verify each cause.
Environment: Local dev, Node 22, Next.js 16 app route.
Error or stack trace:
TypeError: Cannot read properties of undefined (reading 'id')
at getUser (src/lib/users.ts:12:18)
Expected output format
A short plain-language summary, then a ranked list of likely causes, each with a concrete way to confirm or rule it out.
Customization tips
- Include the relevant function body if the stack trace alone isn't enough context.
- Mention what changed recently (a dependency bump, a refactor) to help narrow the cause.
Limitations
- Without the surrounding code, causes are probabilistic guesses, not certainties.
- Version-specific quirks in fast-moving frameworks may not match the assistant's training data.
Safety notes
- Strip file paths, hostnames, or tokens that reveal internal infrastructure before sharing externally.
Refactor for Readability
Ask for a refactor that improves readability or performance while preserving behavior.
Prompt template
Refactor the following {{language}} code to improve {{goal}} without changing its external behavior. Keep the function signature the same unless I ask otherwise. After the refactor, list what changed and why.
Code:
{{code}}
Placeholders
{{language}} — Language- Programming language of the code. Example: Java
{{goal}} — Refactor goal- What to optimize for. Example: readability and reduced nesting
{{code}} — Code- The code to refactor. Example: public boolean isEligible(User u) {
if (u != null) {
if (u.getAge() >= 18) {
if (u.isVerified()) {
return true;
}
}
}
return false;
}
Example input
language: Java · goal: readability and reduced nesting · code: the nested isEligible method above.
Filled-in example
Refactor the following Java code to improve readability and reduced nesting without changing its external behavior. Keep the function signature the same unless I ask otherwise. After the refactor, list what changed and why.
Code:
public boolean isEligible(User u) {
if (u != null) {
if (u.getAge() >= 18) {
if (u.isVerified()) {
return true;
}
}
}
return false;
}
Expected output format
The refactored code block followed by a short bullet list explaining each change and confirming behavior is unchanged.
Customization tips
- Specify constraints such as "no new dependencies" or "must stay compatible with Java 11".
- Ask for the refactor in small, reviewable steps for large functions.
Limitations
- "Behavior preserved" is a claim, not a guarantee — run your existing tests against the refactor.
- Performance claims should be measured with a profiler or benchmark, not assumed from the explanation alone.
Safety notes
- Encourage running the full test suite and, where possible, a code review before merging any refactor.
Write Documentation for a Function
Generate a docstring or comment block describing parameters, return values, and edge cases.
Prompt template
Write documentation for the following {{language}} function in {{doc_style}} style. Describe its purpose, parameters, return value, exceptions or error cases, and one short usage example.
Function:
{{code}}
Placeholders
{{language}} — Language- Programming language of the function. Example: Python
{{doc_style}} — Documentation style- Doc format or convention to follow. Example: Google-style docstring
{{code}} — Code- The function to document. Example: def retry(fn, attempts=3, delay=0.5):
for i in range(attempts):
try:
return fn()
except Exception:
if i == attempts - 1:
raise
time.sleep(delay)
Example input
language: Python · doc_style: Google-style docstring · code: the retry helper above.
Filled-in example
Write documentation for the following Python function in Google-style docstring style. Describe its purpose, parameters, return value, exceptions or error cases, and one short usage example.
Function:
def retry(fn, attempts=3, delay=0.5):
for i in range(attempts):
try:
return fn()
except Exception:
if i == attempts - 1:
raise
time.sleep(delay)
Expected output format
A documentation block in the requested style, including parameters, return value, exceptions, and a short usage example.
Customization tips
- Ask for inline comments in addition to a top-level docstring for complex internal logic.
- Request a matching README section if the function is a public API entry point.
Limitations
- Documentation quality depends on how clearly the code expresses intent; ambiguous code yields ambiguous docs.
- Confirm described exceptions match what the code actually raises.
Safety notes
- Review generated examples for accuracy before publishing them in user-facing documentation.