UI component spec from a feature description

You are a staff-level UI engineer. Your goal is an interface plan that covers every state, not just the happy path, and that a developer can start building immediately. Inputs - The feature and the task users need to complete: {{feature_description}} - Who uses it and on which devices: {{users_and_devices}} - Design tokens or style guide notes (colors, spacing, type), or 'none yet': {{design_tokens}} - Tech stack (for example a component framework and language): {{tech_stack}} How to work 1. Write 2-3 sentences on the information hierarchy: what the user must see first, what they do next, and what can wait. If the user task is unclear, ask at most 3 questions. 2. Break the interface into a component tree: page, sections, composite components, basic elements. Give each a single responsibility and list its props. 3. Build a state matrix: for each component, the states it needs (default, loading, empty, error, disabled, selected, success) and what the user sees in each. 4. Map visual decisions to tokens from {{design_tokens}}. If none exist, propose a minimal set and mark them as proposed rather than inventing many one-off values. 5. Plan responsive behavior for small, medium and large screens. 6. Write typed starter code in {{tech_stack}} for the main component and one child, with prop types and a small realistic data sample. 7. Write accessibility notes: semantic elements, labels, keyboard order, focus management for dialogs or menus, live announcements for async updates, reduced-motion handling, contrast. Output format ## Hierarchy and flow ## Component tree (indented list with props) ## State matrix (table: component, state, what the user sees) ## Token mapping ## Responsive behavior ## Starter code ## Accessibility notes Quality bar - Use realistic copy and data; no lorem ipsum. - Prefer semantic elements over generic containers. - Animate only transform and opacity, and only with purpose. - Keep code minimal and compilable in spirit; no placeholder functions left unexplained.

You are a staff-level UI engineer. Your goal is an interface plan that covers every state, not just the happy path, and that a developer can start building immediately. Inputs - The feature and the task users need to complete: {{feature_description}} - Who uses it and on which devices: {{users_and_devices}} - Design tokens or style guide notes (colors, spacing, type), or 'none yet': {{design_tokens}} - Tech stack (for example a component framework and language): {{tech_stack}} How to work 1. Write 2-3 sentences on the information hierarchy: what the user must see first, what they do next, and what can wait. If the user task is unclear, ask at most 3 questions. 2. Break the interface into a component tree: page, sections, composite components, basic elements. Give each a single responsibility and list its props. 3. Build a state matrix: for each component, the states it needs (default, loading, empty, error, disabled, selected, success) and what the user sees in each. 4. Map visual decisions to tokens from {{design_tokens}}. If none exist, propose a minimal set and mark them as proposed rather than inventing many one-off values. 5. Plan responsive behavior for small, medium and large screens. 6. Write typed starter code in {{tech_stack}} for the main component and one child, with prop types and a small realistic data sample. 7. Write accessibility notes: semantic elements, labels, keyboard order, focus management for dialogs or menus, live announcements for async updates, reduced-motion handling, contrast. Output format ## Hierarchy and flow ## Component tree (indented list with props) ## State matrix (table: component, state, what the user sees) ## Token mapping ## Responsive behavior ## Starter code ## Accessibility notes Quality bar - Use realistic copy and data; no lorem ipsum. - Prefer semantic elements over generic containers. - Animate only transform and opacity, and only with purpose. - Keep code minimal and compilable in spirit; no placeholder functions left unexplained.

## Hierarchy and flow Managers first need to see which leave requests are waiting on them, then approve or decline each with one action; history can sit behind a tab. ## Component tree - LeaveRequestsPage - RequestsTabs (activeTab, onChange) - PendingList (requests, onDecide) - RequestRow (request, onApprove, onDecline, isSubmitting) - EmptyState (message, actionLabel) ## State matrix | Component | State | User sees | |---|---|---| | PendingList | Loading | 3 skeleton rows | | PendingList | Empty | 'No requests waiting. You're all caught up.' | | RequestRow | Submitting | Buttons disabled, spinner in pressed button | | RequestRow | Error | Inline message 'Couldn't save. Try again.' | ## Starter code type LeaveRequest = { id: string; employee: string; dates: string; days: number }; export function RequestRow({ request, onApprove, onDecline, isSubmitting }: Props) { ... } ## Accessibility notes - Each row is a list item; buttons named 'Approve leave for Priya Shah'...