Claude Prompt to Plan React Component Architecture

What this prompt does

This prompt forces an AI assistant to think through a React feature the same way a senior engineer would before writing a single line of code — starting from the component hierarchy and working down through state ownership, data flow, performance tradeoffs, and accessibility. It does not generate a component and move on; it produces a full architectural document you can actually hand to a team.

The template works because it is opinionated about sequence. You define your constraints up front (requirements, state_management, existing_components) so the AI cannot ignore your stack and invent a greenfield solution. The priority_component variable then anchors the starter code to something immediately useful rather than producing abstract scaffolding.

The ten-section output structure is deliberate: each section forces a decision (local vs global state, memo vs useMemo, unit vs E2E) rather than leaving it vague. That specificity is what separates a useful architecture document from a generic "here's a React component" response.

When to use it

• You are starting a net-new feature (dashboard, checkout flow, data table, form wizard) and want alignment before any code is committed.
• You are onboarding a new engineer and need a written architecture reference they can follow independently.
• You are auditing an existing feature for prop-drilling, missing error boundaries, or untested interaction paths.
• You have a Figma design and need to translate it into a component tree and responsibility split.
• You are migrating a class-component feature to functional components with hooks and want a clean cut-point.
• You need to justify a state management choice (Zustand vs Context vs Redux) with documented reasoning, not gut feel.

Example output

For feature_name = "product filter sidebar", state_management = "Zustand", priority_component = "FilterGroup":

Component Tree
└── FilterSidebar (container)
    ├── FilterGroup (price, category, rating)
    │   ├── FilterLabel
    │   └── FilterOption (checkbox/range)
    └── ApplyButton

FilterGroup — TypeScript Props
type FilterOptionItem = { label: string; value: string | number };

interface FilterGroupProps {
  title: string;
  type: 'checkbox' | 'range';
  options: FilterOptionItem[];
  onFilterChange: (key: string, value: unknown) => void;
}

State decision: selected filters live in Zustand (shared with results grid);
open/closed accordion state is local useState — no other component needs it.

Performance: FilterOption wrapped in React.memo — list re-renders on every
Zustand slice update without it. No useMemo needed at FilterGroup level;
derived counts computed in the store selector.

Pro tips

• Set existing_components precisely. If you already have a <DataTable> or <Modal>, name them. The AI will slot them into the tree instead of reinventing them — this is the biggest time saver in the template.
• Use design_reference to paste Figma layer names, not just a URL. Layer names become component names, which prevents the AI from choosing names that conflict with what your team already calls things.
• Run the prompt twice with different state_management values (e.g., Context vs Zustand) to get a comparison before committing to an approach. The data flow section in each output makes the tradeoffs concrete.
• For the convention field in section 9 (File Structure), be explicit: values like feature-folder, atomic-design, or colocation produce dramatically different outputs. If your codebase has no enforced convention, use colocation as a default — it keeps test files and stories next to the component they test.
• The error boundary placement section is often underused. Ask the AI to justify each boundary placement — the reasoning surfaces which async operations are genuinely independent failure domains.
• Treat the testing strategy section as a ticket backlog. Copy the unit/integration/E2E breakdown directly into your issue tracker. It maps cleanly to test file names and test runner commands.