Create a set of 8 copy-paste prompts for a software developer working on [STACK AND PROJECT]. Base them on these recurring responsibilities: [COMMON TASKS]. Follow the engineering rules and constraints in [TEAM STANDARDS]. My typical input material includes [AVAILABLE CONTEXT]. Produce one prompt each for: investigating a bug, planning a change, implementing a small feature, reviewing a pull request, writing tests, explaining unfamiliar code, preparing a database migration, and writing release notes. Each prompt must: - tell the AI what context to request or use, including relevant files, error output, acceptance criteria, and non-functional constraints; - require an explicit assumptions list before recommendations when context is incomplete; - ask for a concrete artifact suited to the task, such as a reproduction plan, file-by-file implementation plan, review comments ranked by severity, test matrix, or rollback steps; - preserve existing interfaces unless a change is justified; - ask the AI to identify security, performance, concurrency, data-migration, and backward-compatibility risks where relevant; - prohibit invented APIs, repository files, test results, or claims that code was run. Format the answer as a table with Task, Copy-Paste Prompt, What to Paste With It, and Expected Output. Keep each prompt between 90 and 150 words and ready to use without editing beyond its bracketed inputs. Then add a short section called “Use carefully” with three cases where a developer must verify the output locally. Before answering, check that every prompt asks for a deliverable rather than generic advice. Check that no prompt implies it has access to my repository or runtime unless I paste that information. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [STACK AND PROJECT] | Name the languages, frameworks, infrastructure, and a brief description of the product or service. | TypeScript, Node.js, PostgreSQL, React; a B2B invoicing application on AWS. |
| [COMMON TASKS] | List the engineering tasks you perform most often. | Investigate production bugs, add API endpoints, review PRs, write Jest tests, and prepare migrations. |
| [TEAM STANDARDS] | Paste relevant conventions for testing, reviews, architecture, security, and deployment. | Use small PRs, Jest and Playwright coverage for changed behavior, parameterized SQL, feature flags for risky releases, and no PII in logs. |
| [AVAILABLE CONTEXT] | Describe the material you can usually provide, such as code excerpts, tickets, logs, and schemas. | Linear ticket, relevant files, failing test output, sanitized logs, API contract, and database schema excerpt. |
How to use
- Paste the prompt and replace all four bracketed inputs with your stack and working practices.
- Keep the generated prompts in a team snippet library, then paste the ticket, files, logs, or diff named by the selected prompt.
- For implementation or debugging output, run the proposed commands and tests yourself before accepting conclusions.
- Follow up with: “Revise the [TASK] prompt for a production incident involving [CONSTRAINT].”
Variations
PR review
Use when you need a single rigorous pull-request review prompt.
Review the pull request diff below for a [LANGUAGE/FRAMEWORK] service. Compare it against [ACCEPTANCE CRITERIA] and [TEAM RULES]. Return findings only when you can point to a file, line, or concrete execution path. Rank each finding as blocking, important, or suggestion; explain the failure mode and a minimal fix. Check authorization, input validation, error handling, race conditions, migrations, observability, tests, and backward compatibility as applicable. Do not praise style or invent repository context. End with a test gap list and questions for the author. Diff: [PR DIFF].
Debug incident
Use when an error is occurring in production or staging.
Help me investigate this [ENVIRONMENT] incident in a [SYSTEM DESCRIPTION]. Evidence: [ERRORS AND LOGS]. Recent changes: [RECENT DEPLOYS OR CONFIG CHANGES]. Produce a ranked hypothesis list, separating evidence from speculation. For each hypothesis, give the smallest safe verification step, expected confirming and disconfirming signals, and whether it can affect data integrity or security. Propose immediate containment only if it is reversible and state its tradeoff. Do not claim access to telemetry or say a cause is confirmed without evidence. End with an incident-update draft limited to 120 words.
Test plan
Use before implementing a change with meaningful edge cases.
Create a test plan for [CHANGE DESCRIPTION] in [SYSTEM]. Existing behavior and interfaces: [CURRENT CONTRACT]. Constraints: [TEST TOOLS AND RELEASE RULES]. Return a table of scenarios with setup, action, expected result, test level, and risk covered. Include happy path, authorization, invalid inputs, boundary values, retries or concurrency where relevant, failure recovery, and backward compatibility. Identify any behavior that needs a product decision rather than an assumed assertion. Recommend the smallest set of automated tests that protects the change, plus any manual verification. Do not invent behavior not supported by the supplied contract.
Tips
- Paste the smallest relevant code slice plus its callers and tests; an isolated function often hides a contract or lifecycle constraint.
- For bug work, provide timestamps, request IDs, versions, and the last known-good behavior so the model can distinguish correlation from evidence.
- Ask for test cases as a matrix before asking for code when the change affects permissions, money, state transitions, or data migrations.
- Treat proposed shell commands and migrations as drafts until they have been checked against your environment and rollback plan.
FAQ
Can AI review a pull request without the whole repository?
Yes, if you include the diff, surrounding interfaces, acceptance criteria, and relevant conventions. It should label anything dependent on missing repository context as an assumption.
Should I paste production logs?
Use sanitized excerpts. Remove credentials, session tokens, customer data, and internal identifiers that are not needed to diagnose the issue.
Will these prompts make the model run my tests?
No. They can propose commands and reason about pasted output, but you must run tests in your own environment.