Create a copy-paste prompt pack for a software engineer working in [TECH STACK] on [SYSTEM CONTEXT]. The engineering standards are [ENGINEERING STANDARDS], and the current work includes [CURRENT WORK]. The available evidence may include code, logs, test output, traces, and documentation: [EVIDENCE TYPES]. Ask up to 3 clarifying questions only if a required input is missing. Then write 10 distinct prompts, each 90–140 words, ready to use in ChatGPT, Claude, or Gemini. Include prompts for: bug triage; root-cause analysis; code review; test-plan design; unit and integration test generation; API contract review; database migration review; performance investigation; technical design proposal; and incident postmortem draft. Every prompt must ask the user to paste the relevant minimal code, error, requirements, and constraints. Require the model to state assumptions, identify unknowns, and cite the exact supplied line, log entry, or requirement behind each conclusion. For code changes, require a minimal diff or patch plan, affected interfaces, failure modes, rollback considerations, and tests that would fail before the fix and pass after it. For security-sensitive code, require review for authorization, input validation, secret exposure, logging of sensitive data, dependency risk, and unsafe deserialization or injection paths. Do not invent repository files, APIs, benchmarks, production access, test results, or root causes. Do not suggest deploying unreviewed changes. Before delivering the pack, check that each prompt specifies its expected output and asks for verification steps. Add a one-line “Evidence required” note below each prompt.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TECH STACK] | Enter the languages, frameworks, databases, infrastructure, and test tools in use. | TypeScript, Node.js 22, Fastify, PostgreSQL 16, Redis, Terraform, GitHub Actions, Vitest. |
| [SYSTEM CONTEXT] | Describe the service or product area, key dependencies, and user impact. | A multi-tenant billing API that creates invoices and exposes account usage to internal and customer-facing dashboards. |
| [ENGINEERING STANDARDS] | State coding, testing, security, performance, and review requirements. | PR review required; 80% coverage for changed modules; tenant authorization on every query; migrations must be backward-compatible and reversible. |
| [CURRENT WORK] | Describe the current features, bugs, migrations, or technical concerns. | Investigating duplicate invoice creation after payment-provider retries and preparing a usage-export endpoint. |
| [EVIDENCE TYPES] | List the kinds of evidence you can provide, such as source files, logs, traces, or dashboards. | Route handlers, SQL queries, queue logs, Sentry traces, Vitest output, and OpenAPI definitions. |
How to use
- Choose the task-specific prompt, then paste only the code, logs, contracts, and requirements needed to analyze it.
- Remove secrets, customer data, tokens, and production identifiers before sharing evidence with an AI tool.
- Run the proposed tests and inspect the patch against repository conventions before opening a pull request.
- Follow up with: “Show the smallest test that reproduces the failure, then explain why it would have failed before the proposed change.”
Variations
Bug triage
Use this when you have a reproducible failure and need a bounded investigation.
Analyze this software bug in [SYSTEM]: [SYMPTOM]. Here are the reproduction steps: [REPRODUCTION], relevant code: [CODE], and evidence: [LOGS OR TRACES]. Produce a ranked list of hypotheses, each tied to specific supplied evidence; a minimal experiment for the top hypotheses; likely blast radius; and the smallest safe fix if confirmed. Separate observations from inferences. Do not claim a root cause without a reproducing test or decisive evidence. Check for concurrency, retries, null handling, authorization, and version mismatches where relevant.
PR review
Use this for a structured review of a proposed change.
Review this proposed change against [REQUIREMENTS] and [REPO STANDARDS]. Diff or code: [CODE]. Return findings ordered by severity: correctness, security, data integrity, concurrency, API compatibility, performance, observability, and test gaps. For each finding, cite the relevant code, explain a realistic failure path, and suggest a focused correction. Do not invent surrounding code. If no blocking issues are evident from the supplied material, say what additional context would be needed before approval.
Design proposal
Use this before implementing a feature with meaningful interface or data-model impact.
Draft a technical design proposal for [FEATURE] in [SYSTEM CONTEXT], based on [REQUIREMENTS] and these constraints: [CONSTRAINTS]. Include goals and non-goals, current-state assumptions, proposed architecture, API and data-model changes, authorization model, failure handling, observability, migration and rollback plan, alternatives, open questions, and test strategy. Mark unsupported assumptions clearly. Do not choose a vendor, estimate capacity, or promise performance without supplied evidence. Keep the proposal under 1,200 words.
Tips
- A log line proves that an event was recorded, not necessarily that it caused the error; ask for a timeline across request, queue, database, and downstream events.
- Generated tests are strongest when you first specify the behavior that must fail before the change, including boundary inputs and retry paths.
- For migrations, inspect read/write compatibility across mixed-version deployments before focusing on the SQL syntax.
- Code-review prompts should include the contract and caller expectations; a diff alone often hides breaking changes at the boundary.
FAQ
Can AI safely write production code?
It can draft code and tests, but it cannot verify your repository, dependencies, runtime behavior, or threat model on its own. Treat its output as a reviewable change, not evidence that the change is safe.
What code should I paste into an AI prompt?
Share the smallest relevant slice plus the interface, error output, and expected behavior. Exclude secrets, tokens, customer data, and proprietary data that your policy does not permit sharing.
Can AI help diagnose an incident?
Yes, it can organize evidence and generate hypotheses. Keep the incident commander’s process, access controls, and rollback decisions with the responsible engineering team.