AI Prompt Templates for Developers: Code Review, Debugging, SQL, and Documentation

Overview

Prompt engineering for developers is most useful when it turns an inconsistent request into a repeatable workflow. A short instruction such as review this code leaves important questions unanswered: What should the model prioritize? Which project conventions apply? Should it suggest changes, rewrite the code, or only report risks? What output format will make the result useful in a pull request?

The templates below are starting points rather than universal solutions. Replace the variables with project-specific information, then test the prompt against representative examples. For higher-risk work, treat the model as an assistant whose suggestions require human review, automated tests, and normal engineering controls.

A strong template usually separates five elements:

• Role: the perspective the model should use, such as a senior reviewer or database engineer.
• Task: the specific action to perform.
• Context: code, requirements, schemas, logs, conventions, or constraints.
• Process: checks or priorities the model should follow.
• Output: the structure, level of detail, and format expected from the response.

For workflows involving retrieved project information, keep source material clearly separated from instructions. The RAG prompt engineering guide provides additional patterns for grounding responses in retrieved context.

Template structure

Use this base structure when creating an AI prompt template for a development task:

Role: You are a {{role}} working within {{project_context}}.

Task: {{specific_task}}

Inputs:
- Language or framework: {{language_and_framework}}
- Relevant code or files: {{code_or_files}}
- Requirements: {{requirements}}
- Constraints: {{constraints}}

Instructions:
1. Inspect the provided inputs before making assumptions.
2. Identify missing information and state any material assumptions.
3. Prioritize {{quality_priorities}}.
4. Do not change behavior outside the stated scope.

Output:
Return {{output_format}}.
Separate findings, recommendations, and unresolved questions.

The variables make the prompt portable, while the output rules make it easier to compare responses across models or prompt versions. Add examples when the desired format is difficult to explain with instructions alone. For instance, show one correctly categorized review finding or one valid SQL response. These few-shot prompting examples should represent the edge cases your team actually encounters, not merely ideal inputs.

For machine-readable results, specify a schema and validate the response in your application. A prompt can request JSON, but application-level validation is still useful. See the comparison of function calling, JSON mode, and plain-text prompting when choosing an output approach.

How to customize

Start with the task, not with a model-specific phrase. Define what a successful result looks like and what the model must not do. Then tailor the template in these areas:

1. Add repository context

Include the relevant language version, framework, directory structure, style rules, dependency constraints, and test commands. Avoid pasting an entire repository when only a few files affect the task. Focused context reduces distraction and makes the response easier to verify.

2. Define risk priorities

For a security-sensitive review, prioritize authorization, input handling, secrets, and data exposure. For performance work, identify the measured bottleneck and the acceptable trade-offs. For a migration, require backward compatibility or a rollback plan if those constraints apply.

3. Control the scope

Tell the model whether it may propose a patch, provide pseudocode, or only explain findings. Ask it to label assumptions and avoid inventing APIs, database columns, test results, or files that were not supplied.

4. Make the output actionable

Useful fields include file and line reference, severity, explanation, suggested change, confidence, and a test recommendation. Output constraints should serve the workflow: a pull request review needs concise findings, while a design investigation may need alternatives and trade-offs.

Keep a versioned copy of each prompt and evaluate changes against a small set of known examples. The prompt evaluation framework can help you define criteria, compare outputs, and track regressions.

Examples

Code review prompt

Act as a careful code reviewer for {{language}} and {{framework}}. Review the code below against these priorities: {{priorities}}.

Requirements:
- Report only issues supported by the provided code.
- Check correctness, security, maintainability, and test coverage.
- Do not comment on formatting unless it affects the project convention or behavior.
- Rank each issue as blocker, important, or suggestion.

Return a table with: severity, location, issue, why it matters, and recommended fix.
End with assumptions and missing tests.

Code:
{{code}}

This template works best when paired with the relevant requirement, surrounding function, and existing tests. Requesting a full rewrite by default can obscure the important findings, so make patch generation a separate step.

Debugging prompt

Act as a debugging partner. Diagnose the issue using only the evidence provided.

Expected behavior: {{expected_behavior}}
Observed behavior: {{observed_behavior}}
Error or logs: {{logs}}
Relevant code: {{code}}
Environment: {{environment}}

Return:
1. The most likely causes, ranked by likelihood.
2. Evidence supporting or weakening each cause.
3. The smallest next diagnostic step for each cause.
4. A proposed fix only after identifying the likely cause.
5. A regression test that would reproduce the issue.

This debugging prompt discourages premature certainty. If the evidence is insufficient, ask the model to identify the next observation needed rather than accepting a confident guess.

Test-generation prompt

Generate tests for {{function_or_component}} using {{test_framework}}.

Inputs:
- Source code: {{source_code}}
- Intended behavior: {{requirements}}
- Existing test patterns: {{examples}}

Cover normal cases, boundary values, invalid inputs, and relevant failure paths. Do not test implementation details unless they are part of the contract. For every test, state the behavior it protects. Return executable test code followed by a short list of untested risks.

SQL prompt

Act as a SQL specialist for {{database_dialect}}.

Goal: {{business_question}}
Schema: {{tables_and_columns}}
Filters and definitions: {{business_rules}}
Constraints: {{performance_or_safety_constraints}}

Write one query and explain its joins, filters, grouping, and assumptions. Use only columns and tables in the supplied schema. Flag ambiguous definitions. Do not modify data unless explicitly requested. Include a validation query or checks for duplicate rows and unexpected nulls where relevant.

For SQL tasks, include the dialect and schema. A query that is valid in one database may not be valid in another, and business terms such as active customer or completed order often need explicit definitions.

Documentation prompt

Write API documentation for {{endpoint_or_module}} using the supplied implementation and examples.

Audience: {{audience}}
Required format: {{format}}
Include: purpose, authentication, parameters, request example, response example, errors, and limitations.

Do not invent behavior. Mark any undocumented detail as an open question. Preserve the terminology used in {{source_of_truth}}.

Refactoring prompt

Propose a low-risk refactor for the code below.

Goal: {{refactoring_goal}}
Must preserve: {{behavior_and_interfaces}}
Constraints: {{dependencies_performance_compatibility}}

First describe the current risks or duplication. Then propose the smallest coherent change, list affected files, and provide a test plan. Do not combine unrelated cleanup. If the goal cannot be met safely with the supplied context, explain what is missing.

When to update

Revisit a developer prompt whenever its inputs, workflow, or quality standard changes. Update the code review template when the team adopts new security checks, languages, frameworks, or review conventions. Update the SQL template when the schema, database dialect, naming rules, or business definitions change. Update documentation prompts when an API contract or publishing format changes.

Also review templates after repeated failure patterns. If outputs contain invented fields, add a source-of-truth rule. If findings are too broad, narrow the scope and provide severity definitions. If responses are difficult to automate, revise the output schema and validate it in the calling application. When a model, context limit, or tool configuration changes, rerun the same evaluation examples before adopting the revised prompt.

A practical maintenance routine is simple:

1. Store each prompt with an owner, version, purpose, and example inputs.
2. Keep a small test set containing normal cases, edge cases, and known failures.
3. Score outputs against task-specific criteria such as correctness, completeness, clarity, and format compliance.
4. Change one major prompt element at a time when possible.
5. Record why a version changed and whether the change improved the target workflow.

Start with one template your team uses frequently, such as code review or debugging. Replace every placeholder, run it against real but appropriately handled examples, inspect the results manually, and then add the checks that matter most to your workflow. For further troubleshooting, see the prompt debugging guide and the guide to building a team prompt playground.