Good AI prompts for developers are not one-off instructions; they are reusable specifications. This library provides copy-and-customize ChatGPT prompt templates and Claude prompt examples for coding, debugging, documentation, requirements analysis, testing, refactoring, and code review, along with a practical method for adapting and evaluating them across different language models.
Overview
Generative AI can support many stages of software development, but the quality of its output depends heavily on the information and constraints supplied in the prompt. A request such as “fix this code” leaves important questions unanswered: What behavior is expected? Which runtime and dependencies are involved? Should the model preserve the existing interface? How should the proposed change be tested?
A reusable prompt answers those questions consistently. It gives the model a defined role, relevant context, a specific task, constraints, and a requested output format. You can then improve the prompt as your team learns which instructions produce useful results.
The templates below are model-agnostic. They can be used with ChatGPT, Claude, or another LLM, but the exact response may vary by model, context window, tool access, system instructions, and temperature settings. Treat every output as a draft or recommendation that requires normal engineering review, testing, and security checks.
For a broader foundation, compare these patterns with the principles in Prompt Engineering Frameworks: How to Write Reliable Prompts for Any LLM. If you are building a repeatable workflow, the evaluation guidance in LLM Prompt Testing: A Practical Framework for Evaluating and Improving AI Outputs can help you move beyond informal experimentation.
Template structure
A strong developer prompt does not need to be long, but it should make the task observable. Use the following structure as a starting point:
- Role or perspective: Define the type of assistance required, such as senior Python reviewer, test engineer, or technical writer.
- Objective: State the outcome in one sentence. Use an action verb such as diagnose, refactor, summarize, generate, compare, or review.
- Context: Include the language, framework, project goal, relevant files, error messages, API contracts, and assumptions. Include only information that helps the task.
- Constraints: Specify compatibility requirements, style rules, performance limits, security considerations, forbidden changes, or dependencies that must remain unchanged.
- Process: Ask for a useful sequence of work, such as identifying assumptions, analyzing the issue, proposing a change, and checking edge cases. This makes the response easier to inspect.
- Output format: Request a clear structure, such as a diagnosis followed by a patch, a Markdown table, test cases, or valid JSON. If the output will be consumed by software, define the required fields.
- Acceptance criteria: Explain what a successful answer must contain or preserve. This is especially important for code generation and requirements analysis.
A general-purpose template looks like this:
Act as a [role] familiar with [language, framework, or domain].
Task: [specific objective]
Context:
- Project or feature: [context]
- Relevant code or requirements: [paste material]
- Current behavior: [what happens now]
- Expected behavior: [what should happen]
Constraints:
- [compatibility, style, security, performance, or scope constraint]
- Do not [explicitly excluded change]
Work through the problem by stating important assumptions, identifying risks,
and proposing the smallest appropriate solution.
Return:
1. [requested explanation]
2. [code, patch, or artifact]
3. [tests or verification steps]
Acceptance criteria:
- [criterion one]
- [criterion two]How to customize
Start with the task, not with a preferred prompt style. A debugging prompt needs reproducible evidence; a documentation prompt needs an audience and terminology; a requirements prompt needs business rules and unresolved questions.
Replace every bracketed placeholder before sending a template. Vague context produces vague output, while excessive context can hide the important signal. A useful practice is to separate facts from assumptions. Label supplied behavior as “observed,” planned behavior as “required,” and uncertain details as “unknown.” Ask the model to identify what it cannot determine rather than silently filling gaps.
Adapt instructions to the model without assuming that a prompt written for one assistant will behave identically in another. Some models may respond well to a direct checklist; others may provide more useful results when the requested deliverable and evaluation criteria are presented first. Keep the core task stable, then test small changes to wording, context order, and output format.
For structured results, specify a schema and include a failure behavior. For example: “Return an object with status, findings, and questions. If the evidence is insufficient, set status to needs_more_context.” When applications consume model output, consider the differences between JSON mode, function calling, and tool use; the guide Function Calling vs JSON Mode vs Tool Use provides a useful decision framework.
Finally, preserve privacy and security. Remove credentials, private keys, personal data, and unnecessary proprietary material. If the task involves an unfamiliar dependency or potentially destructive command, ask for an explanation and a dry-run or review step before execution.
Examples
1. Coding prompt
Act as a senior TypeScript developer.
Implement a function named [function name] that [required behavior].
Context:
- Runtime: [runtime]
- Input shape: [describe input]
- Output shape: [describe output]
- Existing related code: [paste code]
Constraints:
- Preserve the public function signature.
- Do not add dependencies.
- Handle [edge cases].
Return the implementation, a short explanation of key decisions, and unit tests
for normal, boundary, and invalid inputs. Flag any requirement that is ambiguous.2. Debugging prompt
Act as a debugging partner. Diagnose the issue below without assuming that the
first apparent cause is correct.
Environment: [language, version, operating system, framework]
Expected behavior: [expected result]
Observed behavior: [actual result]
Error message or logs: [paste relevant evidence]
Minimal reproduction: [paste code]
Return:
1. The most likely causes, ranked by confidence.
2. The evidence supporting each cause.
3. The smallest safe fix.
4. A corrected code example.
5. Tests or logging steps that would confirm the diagnosis.
Do not invent unseen configuration or claim that the issue is resolved without
identifying how it can be verified.3. Code review prompt
Review the following change as a software engineer focused on correctness,
security, maintainability, and testability.
Repository context: [brief context]
Change or diff: [paste diff]
Review priorities: [list priorities]
For each finding, provide:
- severity: blocker, high, medium, low, or note
- file and location, if available
- problem
- why it matters
- specific recommendation
Separate confirmed issues from questions and do not comment on formatting unless
it affects behavior or the stated standards. End with missing test coverage and a
short summary of what should be checked before merging.4. Requirements analysis prompt
Act as a product-minded business analyst and technical lead. Convert the notes
below into implementable requirements.
Notes: [paste meeting notes, ticket, or user request]
Users: [describe users]
Known constraints: [technical, legal, operational, or timeline constraints]
Return:
- a concise problem statement
- functional requirements
- non-functional requirements
- assumptions
- open questions
- acceptance criteria in Given/When/Then form
- risks and dependencies
Do not resolve ambiguity by guessing. Mark information that requires stakeholder
confirmation.5. Documentation prompt
Act as a technical writer for [audience]. Document the following feature or API.
Source material: [code, schema, examples, or notes]
Audience knowledge: [beginner, intermediate, or expert]
Required sections: [overview, installation, usage, configuration, errors, examples]
Terminology to preserve: [terms]
Use accurate examples based only on the supplied material. Distinguish required
steps from optional guidance. Identify missing information instead of inventing
commands, defaults, or supported features.These templates can also support test generation, refactoring plans, release-note drafts, and migration checklists. For retrieval-based applications, keep retrieved documents clearly separated from instructions and ask the model to cite the supplied context or state when it cannot find support. See RAG Application Tutorial: Build a Retrieval-Augmented Generation Workflow for Trusted Answers for a related workflow.
When to update
Maintain prompt templates like code: review them when their inputs, outputs, or surrounding workflow changes. Revisit a template after changing the programming language, framework, API contract, repository conventions, model, tool permissions, or output parser. A prompt that worked for an interactive chat may need stricter formatting and error handling when placed inside an automated AI development workflow.
Update a template when reviewers repeatedly correct the same issue, when users provide incomplete context, or when generated code passes superficial checks but fails meaningful tests. Record the change, the reason, and a representative set of inputs. Keep a small evaluation set containing ordinary cases, edge cases, ambiguous requests, and known failure cases. Compare versions against the same criteria rather than relying on one impressive response.
A lightweight maintenance record can include:
- template name and intended task;
- model and configuration used for evaluation;
- required inputs and expected output shape;
- quality criteria, such as correctness, completeness, clarity, and safety;
- known failure modes and examples;
- date, owner, and reason for the latest revision.
To put this library into practice, choose one recurring task and customize only one template. Save three to five representative examples, define what a good answer must contain, and test the prompt manually before sharing it with a team or embedding it in an application. Remove instructions that do not improve results, make acceptance criteria explicit, and review every generated change through normal engineering controls. That process turns isolated AI prompts into maintainable developer productivity tools.
