By the end of this page you will have a component that renders the states nobody remembers, handles the keyboard, and reads cleanly enough to reuse. Getting there means deciding the props and state first, writing the JSX second, and hardening it third. The six Claude prompts below follow that order, so you spend less time rewriting and more time shipping.
Step 1 — Define the component before you write JSX
1. Turn a sketch into a spec
You are a React engineer. I want to build a component called [component name] that [component purpose]. Ask me nothing. Write a short spec: the props it needs, the internal state it needs, and the events it should emit. Note which props are required and which are optional.What it does: Turns a loose idea into a clear prop and state contract before any JSX exists.
How to use: replace [component name] and [component purpose]; keep the rest as is.
2. Decide props versus state
For a component that [function], decide what should be a prop and what should be local state. Here is the data it works with: [data description]. Explain each choice in one line, and point out any value that should be derived rather than stored.What it does: Prevents the classic bug of storing something that should be computed from other values.
How to use: replace [function] and [data description]; keep the rest as is.
3. Choose a styling and structure approach
My project uses [styling approach]. Recommend a file structure for [component name], including whether it should hold subcomponents and where the types or prop validation should live. Keep the recommendation short and explain the tradeoff in one line.What it does: Keeps the new component consistent with how the rest of the project is organized.
How to use: replace [styling approach] and [component name]; keep the rest as is.
Step 2 — Build it, then harden it
4. Write the component
Write the React component [component name] using these props: [props list]. It should render [what it shows]. Use [styling approach] and keep the JSX readable. Add a short comment above any logic that is not obvious from the code.What it does: Produces a working first version that matches the spec you just settled.
How to use: replace [component name], [props list], [what it shows], and [styling approach]; keep the rest as is.
5. Add accessibility and keyboard support
Here is my component: [component code]. Make it accessible. Add the right roles and labels, ensure it is reachable and operable by keyboard, and manage focus where needed. Return the updated code and list every change you made in one line each.What it does: Fills the accessibility gaps most first drafts leave out.
How to use: paste your component into [component code]; keep the rest as is.
6. Handle loading, empty, and error states
This component loads data from [data source]: [component code]. Add clear loading, empty, and error states without changing the happy-path design. Explain how each state is triggered and make sure the user always sees what to do next.What it does: Covers the states that make a component feel finished instead of half-built.
How to use: replace [data source] and paste your component into [component code]; keep the rest as is.
Common mistakes
- Skipping the prop and state decision. When it is unclear which value owns the data, bugs multiply later.
- Designing only the happy path. Loading and error states are what users actually hit on slow connections.
- Letting one component grow into everything. Split it before it becomes impossible to test.
Want more like this? Browse the full free library at GuPrompt.
Keep going
- See all Coding prompts.
- Naming everything you just built? Try Gemini prompts for variable naming.
- Studying how others structure results? Read Claude prompts for SERP analysis.