A developer who knows how to prompt well can use AI to do the dull parts of their job — boilerplate, documentation, test scaffolding, code review checklists — without sacrificing control over the architecture decisions that actually matter. The failure mode isn’t using AI too much; it’s prompting it too vaguely and spending more time fixing its output than writing code yourself.
How These Templates Are Organized
The 18 templates are grouped into five categories: code review, refactoring, debugging, test generation, and documentation. Each follows a Role/Task/Context/Format structure that you can paste into ChatGPT, Claude, or — where noted — adapt for Cursor’s inline prompting interface or GitHub Copilot Chat.
Key conventions:
[LANGUAGE]= programming language or framework (Python, TypeScript, Go, etc.)[CONTEXT]= relevant codebase info the model needs (don’t paste entire files — summarize architecture and paste the relevant function/class)[CONSTRAINT]= performance, style, or compatibility constraints
The AI Prompt Generator works well for building custom templates for your specific stack — you can encode your language, framework, and coding conventions in the Context field once and reuse it across prompt types.
Code Review Templates (1–4)
1. General Code Review
Role: You are a senior [LANGUAGE] engineer with strong opinions about maintainability and performance.
Task: Review the following code and identify issues.
Context: This code is part of [DESCRIBE SYSTEM/MODULE]. It runs in [PRODUCTION/STAGING/PROTOTYPE]. Relevant constraints: [PERFORMANCE REQUIREMENTS, STYLE GUIDE, SECURITY CONSIDERATIONS].
Code:
[PASTE CODE]
Format: Categorize issues as: Critical (must fix before merge), Suggested (would improve quality), Nitpick (style/personal preference — can ignore). For each critical issue, include a 1-2 sentence explanation and a corrected code snippet.2. Security-Focused Review
Role: You are a senior application security engineer performing a security code review.
Task: Review the following code for security vulnerabilities.
Context: Language: [LANGUAGE]. This code handles: [USER INPUT / AUTH / DATABASE QUERIES / FILE OPERATIONS — describe what it does]. Known risk areas: [OWASP TOP 10 categories relevant to this code].
Code:
[PASTE CODE]
Format: For each vulnerability found: Severity (Critical/High/Medium/Low) | Vulnerability type | Line reference | Explanation | Recommended fix with code. Sort by severity.3. Performance Review
Role: You are a performance-focused [LANGUAGE] engineer.
Task: Identify performance bottlenecks in the following code.
Context: This function is called approximately [FREQUENCY] per [TIME PERIOD]. Current latency: [OBSERVED LATENCY if known]. The bottleneck hypothesis: [YOUR HYPOTHESIS if any].
Code:
[PASTE CODE]
Format: For each bottleneck: Description | Estimated impact (High/Medium/Low) | Root cause (1 sentence) | Optimized version (code snippet) | Trade-offs introduced by the optimization.4. Pull Request Summary Generator
Role: You are a developer writing a PR description for your team.
Task: Write a pull request description for the following diff/changes.
Context: Branch: [BRANCH NAME]. Related ticket: [TICKET ID/DESCRIPTION]. Type of change: [BUG FIX / FEATURE / REFACTOR / DOCS / TEST].
Changes:
[PASTE DIFF OR SUMMARIZE KEY CHANGES]
Format: PR title (under 72 characters, imperative mood), then sections: Summary (2-3 sentences), Changes made (bullet list), Testing done (bullet list), Screenshots if applicable (leave as placeholder), Checklist (standard items: tests pass, docs updated, no debug code).Refactoring Templates (5–8)
5. Refactor for Readability
Role: You are a [LANGUAGE] engineer focused on clean code and long-term maintainability.
Task: Refactor the following code to improve readability without changing behavior.
Context: Code is in [LANGUAGE]. Team conventions: [NAMING CONVENTIONS, COMMENT STYLE if any]. The next developer reading this will likely be unfamiliar with this module.
Code:
[PASTE CODE]
Format: Refactored code with inline comments explaining non-obvious decisions. A brief summary (3-5 bullets) of what changed and why.6. Extract Functions / Reduce Complexity
Role: You are a senior engineer applying SOLID principles and clean code practices.
Task: Identify functions or classes that are doing too much and refactor them.
Context: Language: [LANGUAGE]. The function/class below has a cyclomatic complexity score of [NUMBER if known] or is [X] lines long.
Code:
[PASTE CODE]
Format: Refactored version with extracted functions/methods. For each extraction: name of new function, its responsibility in one sentence, and why it was extracted.7. Migrate to a New Pattern or Library
Role: You are a [LANGUAGE] developer performing a library or pattern migration.
Task: Rewrite the following code to use [NEW LIBRARY/PATTERN] instead of [OLD LIBRARY/PATTERN].
Context: Codebase context: [RELEVANT ARCHITECTURE INFO]. The migration goal: [WHY YOU'RE MIGRATING — deprecation, performance, standardization]. Breaking changes to be aware of: [ANY KNOWN BREAKING CHANGES].
Code:
[PASTE CODE]
Format: Migrated code with comments on any behavior differences or manual steps required. List any assumptions made.8. Type Safety Improvements
Role: You are a [TYPESCRIPT/PYTHON/RUST] developer who takes type safety seriously.
Task: Add or improve type annotations in the following code.
Context: Current type coverage: [ROUGH ESTIMATE]. Target: [STRICT TYPES / RUNTIME VALIDATION / SCHEMA VALIDATION]. Runtime: [NODE.JS / PYTHON 3.11+ / etc.].
Code:
[PASTE CODE]
Format: Typed version of the code. Highlight any places where full typing required a design decision — describe the decision and why you made it.
Debugging Templates (9–11)
9. Error Diagnosis
Role: You are an experienced [LANGUAGE] debugger.
Task: Diagnose the following error and suggest fixes.
Context: Error message: [PASTE FULL ERROR + STACK TRACE]. What the code is supposed to do: [DESCRIPTION]. What I've already tried: [TROUBLESHOOTING STEPS].
Code:
[PASTE RELEVANT CODE]
Format: Root cause (1-2 sentences), explanation of why the error occurs, ranked list of possible fixes starting with most likely, code snippet for the primary fix.10. Rubber Duck Debug Prompt
Role: You are an experienced developer helping me think through a bug.
Task: Ask me questions to help me identify the root cause of this bug. Do not suggest fixes yet.
Context: What the code should do: [EXPECTED BEHAVIOR]. What it's actually doing: [ACTUAL BEHAVIOR]. When it started: [WHEN IT BROKE — recent change / always been broken].
Code:
[PASTE CODE]
Format: Ask 3-5 clarifying questions that would help narrow down the cause. After I answer, proceed to diagnosis.11. Flaky Test Investigation
Role: You are a senior engineer investigating a flaky test in a CI/CD pipeline.
Task: Analyze the following test and identify why it might fail intermittently.
Context: Language and test framework: [LANGUAGE / JEST / PYTEST / RSpec etc.]. How often it fails: [ROUGH PERCENTAGE]. Environment where it fails: [CI / LOCAL / STAGING]. Suspected cause: [YOUR HYPOTHESIS if any].
Test code:
[PASTE TEST]
Format: Probable causes ranked by likelihood, with explanation for each. For the most likely cause, provide a corrected version of the test. Flag any dependencies on external state, timing, or global variables.Test Generation Templates (12–15)
12. Unit Test Generation
Role: You are a [LANGUAGE] developer writing thorough unit tests.
Task: Write unit tests for the following function/class.
Context: Test framework: [JEST / PYTEST / etc.]. Coverage goal: [HAPPY PATH ONLY / EDGE CASES / FULL BRANCH COVERAGE]. Mocking available for: [EXTERNAL DEPS to mock].
Code to test:
[PASTE CODE]
Format: Full test file with: test for happy path, tests for edge cases (empty inputs, boundary values, null/undefined), tests for error cases. Each test has a descriptive name that reads like documentation.13. Integration Test Scaffold
Role: You are a senior engineer writing integration tests for an API endpoint.
Task: Write integration tests for the [ENDPOINT] endpoint.
Context: Framework: [EXPRESS/FASTAPI/RAILS etc.]. Test runner: [JEST/PYTEST/RSpec]. Database: [DATABASE TYPE]. Auth: [AUTH METHOD]. The endpoint does: [DESCRIPTION].
Format: Test file with setup/teardown, happy path test, auth failure tests, validation error tests, and one edge case specific to this endpoint's business logic. Use real-looking test data, not "foo" and "bar."14. Test Data Generator Prompt
Role: You are a developer creating realistic test fixtures.
Task: Generate test data for the following schema/type.
Context: Schema: [PASTE SCHEMA OR TYPE DEFINITION]. Use case: [WHAT THESE FIXTURES ARE FOR]. Realistic data matters because: [WHY — e.g., testing search, testing formatting, testing validation].
Format: 5 fixture objects as [JSON/YAML/LANGUAGE LITERALS]. Each should represent a meaningfully different case: typical record, edge case (max values, special characters), minimal required fields only, and at least one that should fail validation (label it).15. Snapshot Test Cleanup
Role: You are a frontend developer auditing snapshot tests.
Task: Review the following snapshot test and determine whether it's testing meaningful behavior or just locking in implementation details.
Context: Component: [COMPONENT NAME]. Framework: [REACT / VUE / etc.]. Test runner: [JEST / VITEST].
Snapshot:
[PASTE SNAPSHOT]
Format: Assessment (is this snapshot meaningful or brittle?), specific elements that are meaningful to test vs. elements that will cause false failures on refactors, and a recommended alternative assertion if the snapshot should be replaced.Documentation Templates (16–18)
16. Function/Method Documentation
Role: You are a developer writing documentation that actually helps the next person.
Task: Write documentation for the following function/method.
Context: Language: [LANGUAGE]. Doc format: [JSDoc / Python docstring / Go godoc / etc.]. Audience: developers who are unfamiliar with this module.
Code:
[PASTE FUNCTION]
Format: Full docstring/comment block with: description (what it does, not how), parameters (name, type, description), return value, exceptions/errors thrown, and one usage example.17. README Generator
Role: You are a developer writing a project README for a public or internal repository.
Task: Write a README for the following project.
Context: Project name: [NAME]. What it does in one sentence: [PURPOSE]. Tech stack: [STACK]. Audience: [INTERNAL DEVS / OPEN SOURCE CONTRIBUTORS / BOTH].
Key sections to include: [INSTALLATION / USAGE / CONFIG / CONTRIBUTING — list what applies].
Format: Markdown README with: project name + one-line description, badges (leave as placeholders), table of contents, installation, usage with code example, configuration reference (if applicable), contributing guide (brief), license.18. Architecture Decision Record (ADR)
Role: You are a senior engineer documenting a technical decision.
Task: Write an Architecture Decision Record for the following decision.
Context: Decision: [WHAT WAS DECIDED]. Options considered: [LIST OPTIONS]. Date: [DATE]. Status: [PROPOSED / ACCEPTED / DEPRECATED].
Format: Standard ADR format — Title, Status, Context (why a decision was needed), Decision (what was decided and why), Consequences (positive outcomes, negative trade-offs, risks). Under 500 words.Cursor and GitHub Copilot Tips
Most of these templates work in ChatGPT or Claude via chat. For Cursor and GitHub Copilot Chat, a few adjustments improve results:
Cursor: Use the inline comment trigger (// [PROMPT] above a function) for targeted refactoring. For longer review and documentation prompts, Cursor Chat (Cmd+L) is better — paste your template there. The @codebase context flag pulls in relevant files automatically, which can reduce how much Context you need to provide manually.
GitHub Copilot Chat: Use the /explain, /fix, and /tests slash commands as starting points, then append your Format requirements. For example: /tests Write tests following this format: [your format requirements]. Copilot Chat’s output is shorter than Claude or GPT-4o — use it for small, contained prompts and fall back to a full chat model for complex reviews.
If you’re building a custom prompt template for your team’s specific stack, the AI Prompt Generator lets you encode your architecture context, language, and conventions in the Role and Context fields once, making it fast to generate consistent prompts for your entire team without re-specifying the same codebase context every time.
Frequently asked questions
Do these templates work with Claude Sonnet in Cursor? Yes. Cursor supports Claude Sonnet as the underlying model, and these templates work as-is in Cursor Chat. For inline completions (tab autocomplete), prompts don’t apply — those are driven by the surrounding code context, not explicit prompts.
How much context should I include when pasting code? Paste only the function, class, or file that’s directly relevant. Adding entire codebases causes the model to lose focus on the actual task. For architectural context, write 2-3 sentences describing the surrounding system — that’s usually enough for accurate advice.
Can AI-generated tests replace a real test strategy? No. AI is good at generating test structure and covering obvious cases quickly. It doesn’t know your business rules, your failure modes from production incidents, or the edge cases that actually bite you. Use AI to generate the scaffold (happy path, null checks, boundary values), then add business-logic-specific tests manually.
Should I use ChatGPT or Claude for code review? Claude 3.5 Sonnet and Claude 3.7 Sonnet tend to give more precise, less verbose code feedback and are better at identifying subtle logical errors. GPT-4o handles multilingual codebases and unusual frameworks more reliably. For most teams, test both on 5 real code review tasks and standardize on whichever produces more actionable feedback with fewer false positives.
How do I keep AI code reviews consistent across my team? Standardize on a prompt template and save it in a shared location (Notion, README, Cursor’s custom instructions). The biggest source of inconsistency isn’t model behavior — it’s that different team members ask different questions. A shared template ensures everyone is getting the same categories of feedback.