Create a copy-paste prompt pack for an engineer working on [ENGINEERING CONTEXT]. The pack must help with real day-to-day work while preserving engineering judgment: use supplied code, logs, requirements, and constraints as evidence; never fabricate repository details, test results, benchmarks, API behavior, or incident causes. My environment - Stack and system boundaries: [STACK AND SYSTEM] - Team conventions and constraints: [CONVENTIONS AND CONSTRAINTS] - Common work I need help with: [COMMON TASKS] - Artifacts I can provide to an AI: [AVAILABLE ARTIFACTS] - Experience level and intended audience: [ENGINEER LEVEL AND AUDIENCE] Produce exactly eight distinct prompts, each 90–150 words, for: understanding unfamiliar code, planning a change, debugging, code review, test design, writing documentation, incident analysis, and communicating a technical decision. Each prompt must name the artifacts to paste, specify an output structure, and ask the model to distinguish facts from assumptions and unknowns. Make the debugging prompt begin with reproduction and observability before proposing a fix. Make the code-review prompt prioritize correctness, security, data integrity, concurrency, backward compatibility, performance, and maintainability in that order when relevant. Make the incident prompt avoid blame and separate timeline, contributing conditions, and corrective actions. After the eight prompts, add a one-line note explaining when to use each. Before answering, check that no prompt asks the AI to merge, deploy, delete data, expose secrets, or claim it ran code it cannot access. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [ENGINEERING CONTEXT] | Describe the product, team, or engineering setting these prompts should fit. | A six-person team maintaining a B2B billing product with weekly releases and enterprise customers. |
| [STACK AND SYSTEM] | List languages, frameworks, infrastructure, and important system boundaries. | TypeScript, Node.js, PostgreSQL, React, AWS ECS, Stripe webhooks, GitHub Actions; services communicate over HTTP and SQS. |
| [CONVENTIONS AND CONSTRAINTS] | State repository conventions, security requirements, performance limits, and deployment constraints. | Use ADRs for material decisions, no customer data in logs, migrations must be backward compatible, p95 API latency target is 300 ms. |
| [COMMON TASKS] | List the engineering tasks you do most often or want help with. | Trace billing discrepancies, review pull requests, add API endpoints, write integration tests, and explain tradeoffs to product. |
| [AVAILABLE ARTIFACTS] | List what you can paste, such as code, tests, logs, traces, tickets, or design docs. | Repository files, pull request diffs, test output, sanitized logs, Datadog trace summaries, tickets, and schema migrations. |
| [ENGINEER LEVEL AND AUDIENCE] | State your experience level and who will read the resulting technical work. | Mid-level backend engineer; outputs are shared with senior engineers, product managers, and on-call teammates. |
How to use
- Choose one prompt from the generated pack and paste only the code, logs, ticket text, or design material relevant to that work item.
- Remove secrets, access tokens, customer data, and private keys before sharing artifacts.
- Require the answer to identify assumptions, then validate its proposed path against your repository and test suite.
- Follow up with: “Here is the failing test and sanitized trace. Update the debugging analysis and rank the next three checks by information value.”
Variations
PR review
Use when you need a structured review of a specific pull-request diff.
Review this pull-request diff as a senior engineer. First summarize the intended behavior from the ticket and diff, then list findings by severity: blocking correctness or security issues, important risks, and non-blocking maintainability suggestions. Check data validation, error paths, migrations, concurrency, authorization, backward compatibility, tests, and observability where relevant. Cite the file and line or snippet for each finding. Do not invent repository behavior; label unknown dependencies and ask for needed files. End with a concise approval recommendation. Inputs: [TICKET], [DIFF], [RELEVANT CODE], [TESTS], [SYSTEM CONSTRAINTS].
Debug production issue
Use when you have a reproducible failure or enough telemetry to investigate safely.
Help me investigate this production issue without guessing the root cause. Build a fact table from the symptom, timestamps, affected scope, recent changes, logs, metrics, and traces. Propose the smallest next diagnostic checks ranked by information value, including expected outcomes for competing hypotheses. Only then outline reversible mitigation and permanent-fix options, with risks and validation steps. Do not recommend changing production, deleting data, or exposing sensitive information. Separate evidence from assumptions throughout. Inputs: [SYMPTOM], [SCOPE AND TIMELINE], [RECENT CHANGES], [SANITIZED LOGS AND METRICS], [ARCHITECTURE CONTEXT].
Design proposal
Use before implementation when a change crosses system boundaries or needs team agreement.
Draft a concise engineering design proposal for this change. State the problem, non-goals, requirements, constraints, and success measures. Present two or three feasible approaches with API, data-model, operational, security, rollout, and rollback implications. Recommend one approach only when the supplied evidence supports it; otherwise name the decision required. Include open questions, a phased implementation plan, test strategy, monitoring plan, and migration compatibility checks. Do not fabricate traffic, cost, or performance numbers. Inputs: [PROBLEM AND USERS], [CURRENT SYSTEM], [REQUIREMENTS], [CONSTRAINTS], [EXISTING ARTIFACTS].
Tips
- Give an AI the smallest complete slice of evidence: the failing test, relevant function, input, expected result, and sanitized error often outperform a whole repository dump.
- For debugging, ask for discriminating checks before a fix. A check is valuable when opposite outcomes meaningfully narrow the hypothesis set.
- Treat generated tests as a starting list; verify they cover observable behavior, error paths, boundary values, and the bug’s regression condition.
- Ask the model to cite file names and supplied snippets for claims. Unsupported repository assertions are a signal to inspect rather than trust.
FAQ
Can I paste proprietary source code into an AI tool?
Follow your employer’s approved AI and data-handling policy first. Remove secrets, credentials, customer information, and regulated data unless your approved environment explicitly permits them.
Will AI-generated code be production-ready?
No. It can accelerate drafting and analysis, but engineers still need to validate behavior, security, dependencies, tests, and operational effects in the real system.
Which engineering task benefits most from prompts?
Tasks with clear artifacts and a bounded output work well: explaining an unfamiliar module, enumerating test cases, reviewing a diff, or structuring an incident timeline.