Act as a senior web engineer helping me build this website or feature. Prioritize a maintainable, accessible implementation over a flashy demo. Do not invent APIs, credentials, database fields, package capabilities, legal compliance, performance results, or test results. Product goal and target users: [PRODUCT REQUIREMENTS] Pages, user flows, and acceptance criteria: [USER FLOWS] Current stack, repository structure, and constraints: [TECHNICAL CONTEXT] Data, integrations, authentication, and deployment details: [SYSTEM DETAILS] Design direction and accessibility requirements: [DESIGN REQUIREMENTS] Ask up to 3 clarifying questions only if a required input is missing. Otherwise, start by listing assumptions, ambiguities, and the smallest sensible scope. Return: 1. A concise implementation plan with components, routes, data flow, state ownership, and a file-change list. State what existing code you need to inspect before modifying it. 2. Production-ready code for the requested scope, organized by file path. Include only files that need to be added or changed. Explain non-obvious decisions after each file. 3. For every form or user action, specify loading, empty, error, success, retry, keyboard, and mobile behavior. Validate on the server as well as the client when data reaches a server. 4. An accessibility checklist covering semantic structure, labels, focus order, visible focus, error announcements, contrast, and non-mouse operation. 5. A verification plan with unit, integration, and manual test cases, including at least one unhappy path. Use the conventions in [TECHNICAL CONTEXT]; if they conflict with a request, explain the tradeoff before coding. Before answering, check that all imported libraries are either already available or explicitly called out for installation, and that no secret or privileged operation is exposed to the browser.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT REQUIREMENTS] | Describe the user problem, audience, and outcome the website or feature must deliver. | A local bakery needs a site where customers can browse weekly items and submit a pickup request; staff confirm requests manually. |
| [USER FLOWS] | List the pages, key interactions, acceptance criteria, and examples of successful completion. | Home shows featured items; menu filters by dietary tag; pickup form collects item, quantity, date, name, email, and phone; confirmation explains staff will respond within one business day. |
| [TECHNICAL CONTEXT] | Provide the framework, language, existing patterns, relevant file tree, and technical restrictions. | Next.js 15 App Router, TypeScript, Tailwind, React Hook Form, Zod. Existing components live in src/components and use named exports. |
| [SYSTEM DETAILS] | Describe known APIs, data fields, authentication, integrations, environment variables, and deployment setup. | POST /api/pickup accepts {itemId, quantity, pickupDate, name, email, phone}; no user accounts; server sends email through an existing internal service. |
| [DESIGN REQUIREMENTS] | State visual direction, responsive behavior, supported browsers, and accessibility requirements. | Warm but restrained editorial style; mobile first; WCAG 2.2 AA; support current Chrome, Safari, Firefox, and Edge. |
How to use
- Paste the prompt with your real stack and acceptance criteria, then include the relevant existing files before requesting changes.
- Check the proposed file list against your repository so the AI does not overwrite patterns or invent endpoints.
- Run the verification plan locally, including validation errors, slow network behavior, keyboard navigation, and a narrow mobile viewport.
- Follow up with: "Here is the current implementation and test output. Diagnose the failing case without changing unrelated files: [CODE AND OUTPUT]."
Variations
Frontend component
Use when you need one reusable interface component rather than a full site.
Build an accessible reusable [COMPONENT NAME] for this application. Framework and styling conventions: [STACK]. Required states and interactions: [REQUIREMENTS]. Existing component APIs to match: [EXAMPLES]. Provide a typed public API, files to add or change, implementation code, usage example, and tests. Cover keyboard controls, focus management, disabled/loading/error states, and responsive behavior. Do not add dependencies unless you name and justify them. Check that the component has a semantic accessible name and does not trap focus.
API-backed feature
Use when a browser UI must safely call a backend service.
Design and implement this API-backed web feature: [FEATURE]. Current frontend and backend stack: [STACK]. Existing endpoint contract and auth model: [API CONTRACT]. Validation and business rules: [RULES]. Produce a request/response contract, server validation plan, client states, code by file path, and tests for authorization, invalid input, timeout, and duplicate submission. Do not expose secrets or trust client validation as authorization. Check that each error maps to a safe user message and an actionable server log.
Website code review
Use when a page exists and you need focused engineering feedback.
Review this website implementation against its requirements. Requirements: [REQUIREMENTS]. Code and relevant files: [CODE]. Stack and deployment constraints: [CONTEXT]. Return prioritized findings with severity, evidence, user impact, and a minimally invasive fix. Cover correctness, accessibility, security boundaries, responsive layout, performance risks, and test gaps. Do not claim a live test passed unless I supplied results. Check that every finding refers to code or a stated requirement, not a generic best practice.
Tips
- Give the AI an endpoint contract and existing component conventions before requesting code; otherwise generated code often creates incompatible assumptions.
- Treat client-side validation as usability, not security; validate and authorize again wherever the server receives a request.
- Specify empty, loading, failure, retry, and duplicate-submit behavior before coding because these states shape the component architecture.
- Test keyboard flow and form errors at a narrow viewport; visual success at desktop width does not establish an accessible working page.
FAQ
Can I paste AI-generated code directly into production?
Not without reading it and testing it in your actual project. Generated code may assume packages, APIs, or security conditions that do not exist.
What information produces better website code?
The existing stack, file patterns, endpoint contracts, acceptance criteria, and screenshots or design rules are more useful than a broad description of the visual style.
Can AI check website accessibility?
It can identify likely issues and create test cases, but you should also run automated checks and test keyboard and assistive-technology flows in the real interface.