Help me implement [FEATURE OR BUG] in an existing React application. Project context: [PROJECT CONTEXT] Current relevant code: [RELEVANT CODE] Constraints: [TECH STACK AND CONSTRAINTS] Expected behavior and acceptance criteria: [ACCEPTANCE CRITERIA] First, identify the smallest sensible component, hook, state, and API boundaries. State any assumptions, but do not invent files, endpoints, package APIs, types, or product rules that I have not provided. If a required input is missing, ask up to 3 focused clarifying questions before proposing code.
Then produce: 1. A short implementation approach naming the files to change and why. 2. Complete, paste-ready code for each changed file, preserving the conventions visible in my code. Use TypeScript types if the project uses TypeScript. 3. An explanation of state flow: what owns each state value, what triggers updates, and how loading, empty, error, and retry states behave. 4. Focused tests using the existing test stack, covering the main user path and the highest-risk edge cases. 5. A short manual QA checklist. Apply React-specific checks before answering: avoid derived state unless it is necessary; avoid mutating state; use stable list keys based on data identity rather than array position; clean up effects and abort or ignore stale async work where relevant; and do not add useMemo, useCallback, or an effect unless it solves a demonstrated problem. Include labels, keyboard behavior, focus handling, and meaningful status announcements for any interactive UI. Flag any acceptance criterion that the supplied code or context cannot support.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [FEATURE OR BUG] | Describe the user-facing feature to build or the defect to fix. | Add a searchable customer selector to the invoice form; fix stale results when the user types quickly. |
| [PROJECT CONTEXT] | State the app purpose, relevant route, existing component conventions, and data flow. | React 19 + Vite admin app. InvoiceForm owns form state; TanStack Query fetches API data; CSS modules. |
| [RELEVANT CODE] | Paste the component, hook, types, and API code that the change touches. | InvoiceForm.tsx has a customerId field; useCustomers.ts accepts a search string and calls GET /api/customers?q=. |
| [TECH STACK AND CONSTRAINTS] | List React version, framework, styling, state, test tools, and constraints such as no new dependencies. | TypeScript, React Hook Form, Vitest, Testing Library. No new packages; retain the current API contract. |
| [ACCEPTANCE CRITERIA] | List observable behaviors that must work, including error or empty cases. | Search starts after two characters, shows loading and no-results states, keyboard selection works, and the chosen customer is submitted as customerId. |
How to use
- Paste the prompt, then replace every bracketed input with code and context from the actual feature.
- Include the existing types and API shape so the model does not guess contracts.
- Check that each proposed file and import exists, then run the supplied tests and the manual QA checklist.
- Follow up with: "Now review this diff against the acceptance criteria and list only concrete defects or missing tests."
Variations
React code review
Use this after you have a diff and want a React-focused review.
Review this React change for correctness and maintainability. Diff or files: [CODE OR DIFF] Expected behavior: [ACCEPTANCE CRITERIA] Project conventions: [CONVENTIONS] Return findings only, ordered by severity: blocking bug, likely bug, accessibility issue, test gap, then optional simplification. For every finding, cite the exact component or code path, explain the user impact, and give a minimal repair. Check state ownership, effect dependencies, stale async responses, controlled inputs, list keys, cleanup, and keyboard/focus behavior. Do not claim a problem without evidence in the code. Ask up to 3 questions only if a missing file prevents review.
Component design
Use this before coding a new screen or complex reusable component.
Design a React component architecture for [FEATURE]. Users and workflow: [USER FLOW] Available data and actions: [DATA CONTRACT] Existing app conventions: [CONVENTIONS] Provide a component tree, prop and event contracts, state ownership, error/loading/empty behavior, and a file plan. Separate server data from transient UI state and explain each boundary. Include accessibility requirements for interactive elements and identify the one or two components that deserve tests first. Do not write implementation code yet or invent API fields. Ask up to 3 clarifying questions only if a required product rule or data contract is absent.
React bug diagnosis
Use this when a component behaves incorrectly and you need a reproducible diagnosis.
Diagnose this React problem: [SYMPTOM]. Relevant code: [CODE] Reproduction steps: [REPRODUCTION] Observed versus expected result: [EXPECTED VS ACTUAL] Give a ranked list of plausible root causes tied to exact code paths, then the smallest safe fix and a regression test. Consider stale closures, incorrect dependency arrays, event ordering, controlled/uncontrolled inputs, state mutation, key reuse, and async races. Distinguish confirmed evidence from hypotheses. Do not rewrite unrelated code or invent runtime output. Ask up to 3 questions only if the reproduction or code omits a necessary detail.
Tips
- Paste the types and the actual API response before asking for UI code; most React mistakes here are contract guesses, not JSX mistakes.
- For async search, test a slow earlier request followed by a fast later request, because stale-result bugs often escape happy-path tests.
- Ask for a component’s owner of state in plain language; duplicated state across a form and child selector is a common source of drift.
- Treat accessibility as behavior: verify tab order, Enter and Escape behavior, focus after a selection, and the message a screen reader receives.
FAQ
Can an AI write an entire React component from a short description?
It can draft one, but provide the current types, state library, API contract, and acceptance criteria. Otherwise it may produce plausible code that does not fit your application.
Should I ask it to use useMemo or useCallback?
Only when you can name the performance or identity issue. Unnecessary memoization makes code harder to reason about and can hide dependency errors.
How do I use this for a bug?
Include a minimal reproduction, expected versus actual behavior, and the exact relevant code. Ask for a regression test alongside the fix.