The Best Prompt for Building a React Component

# Role
You are a senior React engineer. You write components that are easy to test, accessible by default and no more abstract than the job requires.

# What I'm building
- Component or feature: A sortable, filterable orders table with row selection
- Behavior and requirements: Sort by date, customer or total. Filter by status (pending, shipped, refunded). Select rows with checkboxes, including select-all for the current page, and export selected rows as CSV. Sort and filter persist in the URL query string.
- Stack: React 19, TypeScript, Vite, TanStack Query v5, React Router v7, CSS Modules
- Where the data comes from: GET /api/orders?status=&sort=&page= returns { items: Order[], total: number }. Order = { id: string; customer: string; total: number; status: 'pending' | 'shipped' | 'refunded'; createdAt: string }
- Existing code or conventions to follow: We have Button, Checkbox and Select components in src/ui. Files are named PascalCase.tsx with a matching .module.css.

# Part 1: design note (before any code)
Keep this short. Cover:
1. Component breakdown: each component, its single responsibility and its props as a type.
2. State: every piece of state, where it lives and why. Name the values that are derived and therefore not stored.
3. Effects: each effect and the external system it synchronizes with. If something can be computed during render or handled in an event handler, do that instead and say so.
4. UI states: loading, empty, error, partial data, plus anything these requirements imply.

# Part 2: implementation
- Function components and hooks only.
- Complete files, each under a heading with its file path. No elided sections and no "rest of the code here".
- Semantic HTML first. Add ARIA only where no native element does the job. Every interactive element must be operable by keyboard and show visible focus.
- Keys come from stable data ids, never array indexes for lists that can reorder.
- Do not add memo, useMemo or useCallback unless you name the specific re-render or cost it prevents.
- Use only the libraries in the stack. If another dependency seems warranted, propose it in one line instead of importing it.
- Do not invent endpoints, response fields or props of existing components. Where a shape is unknown, define a clearly named placeholder type and mark it with a TODO comment.

# Part 3: after the code
- Tests (React Testing Library with Vitest): list the behaviors worth testing as user-visible scenarios. Unless the approach says scenarios only, write the tests for the three most important.
- Assumptions: what you guessed about requirements or data.
- Not handled: edge cases you deliberately left out.

# Output format
Design note, then one code block per file, then Tests, Assumptions and Not handled. Outside code blocks, use short bullets only.