Code Generation & Software Engineering Prompts

You are a senior software engineer writing unit tests.

Function to test:
[PASTE THE FUNCTION CODE]

Language and test framework: [E.G. TYPESCRIPT WITH VITEST, PYTHON WITH PYTEST]

Instructions:
1. Write tests covering normal, expected inputs.
2. Write tests covering edge cases: empty input, null/undefined, boundary values.
3. Write tests covering any error conditions the function should raise or handle.
4. Use clear, descriptive test names that state what is being verified.
5. Return only the test code, in a single code block, ready to run.

Output format: one fenced code block containing the complete test file.

Role: You are a senior software engineer specializing in code readability and maintainability.

Context:
Language/framework: [LANGUAGE_AND_VERSION]
Style guide or conventions to follow: [STYLE_GUIDE_OR_LINTING_RULES]
What this code does: [BRIEF_DESCRIPTION_OF_FUNCTIONALITY]
Constraints (things that must not change): [PUBLIC_API_SIGNATURES_OR_OTHER_CONSTRAINTS]

Code to refactor:
[PASTE_FULL_FUNCTION_OR_FILE_HERE]

Instructions:
1. Refactor the code for readability and maintainability: clearer naming, smaller single-purpose functions, removed duplication, reduced nesting.
2. Do not change external behavior or any stated constraints (public API, function signatures used elsewhere).
3. List each change you made, one by one, with a short reason for it.
4. Suggest 2-3 test cases I should run to confirm the refactor preserves the original behavior.
5. If any part of the code is ambiguous or you're unsure of intended behavior, flag it instead of guessing.

Output format:
1. Refactored code in a fenced code block
2. A numbered list of changes with a one-line reason for each
3. Suggested test cases

You are an experienced software engineer performing a code review. Review the following code change for issues a careful human reviewer would catch before approving a pull request.

Context:
- Language/framework: [LANGUAGE AND FRAMEWORK]
- Style guide or conventions to follow: [STYLE GUIDE, e.g. PEP 8, Airbnb JS, or "none specified"]
- Purpose of this change: [ONE-SENTENCE DESCRIPTION OF WHAT THE CHANGE DOES]

Code to review:
[PASTE DIFF OR FULL FILE CONTENTS HERE]

Review the code across these categories, in this order:
1. Correctness — logic errors, edge cases, off-by-one errors, null/undefined handling
2. Security — injection risks, unvalidated input, broken access control, exposed secrets
3. Readability — unclear naming, missing comments where logic is non-obvious, overly complex functions
4. Performance — unnecessary loops, redundant computation, inefficient queries
5. Test coverage — missing tests for new logic or edge cases

Constraints:
- Cite the specific line number or exact code snippet for every finding
- Label each finding as Blocking, Should-fix, or Nitpick
- Do not rewrite the code — describe the issue and suggest a fix in words
- If a category has no issues, state that explicitly rather than skipping it

Output format:
For each category, list findings as:
[Severity] Line/snippet: [code reference]
Issue: [what's wrong]
Suggested fix: [brief description]

End with a one-line overall verdict: Approve, Approve with comments, or Request changes.

ROLE: You are an experienced [PROGRAMMING LANGUAGE] developer helping debug a runtime error.

CONTEXT:
- Language/runtime: [LANGUAGE AND VERSION, e.g. Python 3.11, Node 20]
- Framework/libraries involved: [FRAMEWORK NAMES AND VERSIONS]
- What the code is supposed to do: [BRIEF DESCRIPTION OF THE FEATURE OR FUNCTION]
- Error message and full stack trace:
[PASTE FULL ERROR MESSAGE AND STACK TRACE HERE, TOP TO BOTTOM, UNEDITED]

- Relevant source code (include every function/file named in the trace):
[PASTE CODE FOR EACH FRAME IN THE STACK TRACE]

- What I've already tried: [LIST ANY FIXES OR CHECKS ALREADY ATTEMPTED, OR WRITE "NOTHING YET"]

CONSTRAINTS:
- Do not suggest a fix until you've identified the specific line and condition that triggers the exception
- If the trace doesn't contain enough information to be certain, say so and list what additional information (logs, input values, config) would confirm the cause
- Do not assume framework defaults that weren't stated — ask if a detail is missing rather than guessing

OUTPUT FORMAT:
1. Root cause analysis: the most likely cause, tied to the exact line/frame in the trace
2. Alternative hypotheses: 1-2 other possible causes, ranked by likelihood, each with what evidence would confirm or rule it out
3. Suggested fix: the minimal code change to resolve the most likely cause
4. Verification step: how to confirm the fix actually resolves the error (a test to run, a log line to check, an input to retry)

ROLE: You are a senior software engineer writing a commit message and pull request description for a code change.

CONTEXT:
- Code diff or summary of changes: [PASTE DIFF OR DESCRIBE THE CHANGE]
- Related ticket/issue: [TICKET ID AND TITLE, OR "NONE"]
- Commit convention to follow: [E.G. CONVENTIONAL COMMITS, FREEFORM, TICKET-PREFIXED]
- Audience for the PR description: [E.G. TEAM ENGINEERS, EXTERNAL CONTRIBUTORS]

TASK:
1. Write a commit subject line under 72 characters that follows the specified convention.
2. Write a 2-4 sentence commit body explaining what changed and, if context was given, why.
3. Write a pull request description with these sections: Summary, Why This Change Is Needed, How It Was Tested, Risk/Areas to Review Closely.
4. If the diff includes a schema change, new dependency, or breaking change, call it out explicitly under Risk/Areas to Review Closely.

CONSTRAINTS:
- Do not invent functionality, reasoning, or test coverage that wasn't stated or shown in the diff.
- Keep the PR description skimmable — short paragraphs or bullets, not dense prose.
- If information needed for a section is missing, write "Not specified" rather than guessing.

OUTPUT FORMAT:
Commit Subject: [text]
Commit Body: [text]

PR Description:
## Summary
[text]
## Why This Change Is Needed
[text]
## How It Was Tested
[text]
## Risk / Areas to Review Closely
[text]