Help me implement a web-development task safely and correctly. Project context - Task or user story: [TASK] - Existing stack and relevant versions: [TECH STACK] - Current code, error output, or relevant files: [CURRENT CONTEXT] - Required behavior and acceptance criteria: [ACCEPTANCE CRITERIA] - Constraints: [CONSTRAINTS] Ask up to 3 clarifying questions only if a required input is missing. Do not invent APIs, package behavior, database fields, credentials, file contents, or test results. If the task affects payments, authentication, personal data, permissions, or production infrastructure, call out the risk and recommend an appropriate review. First, state the likely approach in 5-10 bullets: affected components, data flow, dependencies, assumptions, and alternatives rejected. Then produce a complete implementation in the requested language and framework. Show each changed file under a clear filename label, with code that can be copied directly. Preserve existing patterns from [CURRENT CONTEXT] where they are supplied. Include a verification section with unit, integration, and manual test cases as appropriate. Cover loading, empty, error, unauthorized, duplicate-submission, mobile, keyboard, and screen-reader behavior where relevant. Include validation and error messages at the boundary closest to the user, while keeping server-side validation authoritative. Note performance concerns such as unnecessary requests, large payloads, N+1 queries, and unsafe client exposure of secrets. Self-check before answering: verify imports, identifiers, and data shapes agree across every code block; then list any assumptions or unverified framework details. Explain rather than hide tradeoffs.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TASK] | Describe the feature, bug, or technical question and the expected user outcome. | Add a saved-search feature to a job board so signed-in users can save filters and receive a confirmation. |
| [TECH STACK] | List the framework, language, runtime, database, and relevant library versions. | Next.js 15, TypeScript, App Router, Prisma 6, PostgreSQL, Zod, React Hook Form. |
| [CURRENT CONTEXT] | Paste relevant code, file paths, error messages, or describe the existing architecture. | app/jobs/page.tsx has URL filter parsing; prisma schema has User and Job but no SavedSearch; server actions are used for mutations. |
| [ACCEPTANCE CRITERIA] | List observable requirements that determine whether the work is complete. | Users can name and save a filter set, see their saved searches, cannot save an empty name, and cannot access another user's searches. |
| [CONSTRAINTS] | State compatibility, security, design-system, performance, deployment, or time constraints. | Use existing server-action patterns; no new UI library; support keyboard use; do not send email yet. |
How to use
- Paste the relevant files and exact error output, not only a description of the problem.
- Compare the proposed approach with your repository conventions before copying code.
- Run the suggested tests and manually exercise empty, error, and permission states.
- Follow up with: “Review this implementation against the acceptance criteria and show only necessary fixes.”
Variations
Bug Diagnosis
Use when a page or endpoint fails and you need a focused root-cause analysis.
Diagnose this web bug using [EXPECTED BEHAVIOR], [ACTUAL BEHAVIOR], [REPRODUCTION STEPS], [RELEVANT CODE], and [ERROR OUTPUT]. Start with the three most likely causes ranked by evidence, then identify the smallest safe fix. Provide a patch by file, tests that would fail before and pass after, and a regression explanation. Do not invent logs, code paths, or dependency behavior. Ask up to 3 clarifying questions only when a missing input prevents diagnosis.
API Contract
Use when defining a frontend-backend boundary before coding.
Design an API contract for [FEATURE], [CLIENT NEEDS], [DATA MODEL], [AUTHORIZATION RULES], and [ERROR CONVENTIONS]. Produce endpoints or RPC methods, request and response schemas, status codes or typed errors, validation rules, pagination or idempotency behavior, and example requests. Include authorization checks and backwards-compatibility risks. Do not create fields not supported by the data model; label proposed additions. Ask up to 3 clarifying questions only if required inputs are missing.
Code Review
Use when you have an implementation and want a practical review.
Review [CODE OR DIFF] for [INTENDED BEHAVIOR] in a [TECH STACK] application, considering [RISK AREAS] and [PROJECT CONVENTIONS]. Return findings ordered by severity with exact file locations, the failure scenario, and a concrete fix. Check correctness, security, authorization, async behavior, validation, accessibility, tests, and maintainability. Do not praise or rewrite unrelated code. Ask up to 3 clarifying questions only if missing context makes a finding uncertain.
Tips
- Give the model the smallest relevant file set plus the exact version of the framework; version-sensitive APIs are a frequent source of plausible but broken code.
- Write acceptance criteria as observable behavior, including who is allowed to perform the action and what happens when it fails.
- Treat generated migrations, authentication changes, and payment code as drafts until reviewed and tested in a safe environment.
- Ask for tests before implementation when the behavior is complex; it exposes ambiguous requirements early.
FAQ
Can I paste a whole repository into the prompt?
Usually no. Start with the files on the request path, data schema, and error output, then add context only when the model identifies a dependency.
Will generated code be production-ready?
It can be a strong starting point, but you still need local tests, dependency checks, and review for security-sensitive changes.
What should I do when the AI suggests a package I do not use?
Ask it to revise using your existing dependencies, or request a comparison that includes maintenance, bundle, and migration costs.