Act as a senior web engineer pairing with me on this task: [ENGINEERING TASK]. The relevant code or file excerpts are [CODE CONTEXT]. My stack and versions are [STACK AND VERSIONS]. The expected behavior and acceptance criteria are [ACCEPTANCE CRITERIA]. Constraints include [CONSTRAINTS]. Do not assume unavailable libraries, API fields, environment variables, database columns, or product requirements. If a decision depends on an unspecified fact, state the assumption and offer the smallest safe default. Respond in this order: 1. Restate the problem in 3-5 precise bullets, including inputs, outputs, and ownership boundaries. 2. Identify the likely implementation path, affected files or modules, data flow, and any migration, authorization, caching, concurrency, accessibility, or backwards-compatibility concerns that actually apply. 3. Provide a numbered implementation plan before code. 4. Write production-ready code changes. Label each file path, include only necessary surrounding context, and explain non-obvious lines. Preserve existing conventions from [CODE CONTEXT]. 5. Provide focused tests with named cases for the happy path, validation or malformed input, empty/loading/error states where relevant, and the most likely regression. 6. Include a manual verification checklist and a rollback note if the change touches persistent data or an external API. Prefer small, composable changes over a rewrite. Do not claim code was run. Ask up to 3 clarifying questions only if a required input is missing; otherwise proceed with clearly labeled assumptions. Before answering, self-check that every acceptance criterion has a corresponding implementation or test and that code handles errors at the system boundary rather than silently swallowing them.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [ENGINEERING TASK] | Describe the feature, bug, or refactor and the user-visible outcome. | Add server-side pagination and filters to the customer orders table |
| [CODE CONTEXT] | Paste relevant files, interfaces, error output, or a concise repository convention summary. | Next.js App Router, Prisma Order model, existing route at app/api/orders/route.ts; table currently loads all orders client-side |
| [STACK AND VERSIONS] | List the framework, language, runtime, database, and key library versions involved. | TypeScript 5.6, Next.js 15, React 19, PostgreSQL 16, Prisma 6 |
| [ACCEPTANCE CRITERIA] | List observable conditions that must be true when the work is complete. | Filter by status and date range; show 25 rows per page; preserve filters in the URL; reject invalid dates |
| [CONSTRAINTS] | State limits such as no new dependencies, performance targets, deployment rules, or compatibility needs. | No new packages; existing admin authorization must remain; table may contain 500,000 orders |
How to use
- Paste the task, the smallest code slice that establishes local conventions, and exact acceptance criteria.
- Check the assumptions section before copying code, especially data ownership and existing authorization behavior.
- Run the proposed tests and manually test the listed boundary cases in your environment.
- Follow up with: “Here is the actual failing test or review feedback: [DETAIL]. Revise only the affected plan and code.”
Variations
Bug investigation
Use this when you have a reproducible defect but not a confirmed cause.
Help me diagnose this web application bug without jumping to a patch. Symptoms are [SYMPTOMS], reproduction steps are [REPRODUCTION STEPS], relevant logs are [LOGS], and code context is [CODE CONTEXT]. Give a ranked hypothesis list with evidence for and against each, the lowest-cost diagnostic check, and the smallest safe fix only after the likely cause is established. Include a regression test plan. Do not invent log output or say you reproduced it. Ask up to 3 questions only if required context is absent. Self-check that each hypothesis explains all reported symptoms.
Code review
Use this before merging a focused pull request.
Review this proposed change as a senior web engineer: [DIFF OR CODE]. The intended behavior is [INTENDED BEHAVIOR], and the system context is [SYSTEM CONTEXT]. Return findings ordered by severity: correctness, security and authorization, data integrity, performance, accessibility, maintainability, then test gaps. For every finding, cite the relevant code behavior, explain a plausible failure case, and suggest a minimal fix. Do not praise or rewrite unrelated code. Ask up to 3 clarifying questions only if necessary. Self-check that no finding relies on an unstated framework behavior.
API design
Use this when defining an endpoint before implementation.
Design an API contract for [API PURPOSE]. Consumers are [CONSUMERS], resources and fields are [RESOURCE DETAILS], and constraints are [CONSTRAINTS]. Specify method and path, authentication and authorization rules, request schema, response schemas with examples, pagination or filtering semantics, validation errors, idempotency where relevant, and versioning or compatibility notes. Then list implementation risks and contract tests. Do not add fields that the resource details do not support. Ask up to 3 questions only if a required input is missing. Check that every mutation has a clear failure response.
Tips
- Give the model the interface and the failing behavior, not an entire repository dump; local types, route handlers, and one related test are usually the highest-signal context.
- Write acceptance criteria as observable outcomes, including invalid input and authorization, so the proposed tests are not limited to a happy path.
- For database-backed lists, specify expected row count and sorting; pagination without a stable, indexed ordering produces duplicates or gaps.
- Treat generated dependency upgrades and schema migrations as separate changes unless they are required for the task, because they enlarge review and rollback scope.
FAQ
Can I paste proprietary code into an AI prompt?
Follow your company’s data policy and remove secrets, customer data, tokens, and production credentials. A small redacted excerpt is often enough.
Will the generated code work without changes?
It may need adaptation to your repository’s types, conventions, and versions. Run tests and examine assumptions before merging.
What makes an AI-generated test useful?
It should assert the contract that could regress: authorization, invalid input, ordering, state transitions, or an error boundary—not only that a component renders.