Choose an intent and domain, review the guardrails, then copy the exact published instruction. SkillCodex generates, sends, and executes nothing.
Loading the prompt gallery…
Audience measurement
With your consent, Google Analytics measures how the site is used to help us improve it. Your choice is stored on this device and can be changed anytime via “Cookies” in the footer.
86 prompts
Page 1 of 4
UI·Build·Tooltip
Build Tooltip without breaking its behavior
# Implement Tooltip in your agent
## Objective
Implement Tooltip for this verified behavior: A short, noninteractive hint that appears when a control receives pointer hover or keyboard focus.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Tooltip matches the need before writing code.
## Required behavior
- Pointer hover or keyboard focus reveals the information after a short delay.
- Escape closes the tooltip without moving focus away from its trigger.
## States to cover
- Tooltip hidden
- Tooltip visible
## Accessibility
- ARIA role: tooltip
- The primary control or named region for Tooltip has a stable accessible name from visible text or an explicit programmatic label.
- Focus remains on the trigger; the tooltip itself never enters the tab order.
- It closes on Escape and after both focus and pointer leave the trigger and surface.
- The trigger references the tooltip description so assistive technology can read it without moving focus.
- Tab focuses the trigger
- Escape dismisses the visible tooltip
## When not to use
- The information is essential to completing the task
- The content needs links, buttons, or form controls
## Acceptance criteria
- The same hint is available on hover and keyboard focus
- The tooltip contains no interactive control
- Escape closes it without moving focus
- Touch users are not denied essential information
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-tooltip
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Tooltip on a real journey
# Verify Tooltip after implementation
## Objective
Audit the Tooltip implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Tooltip in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Tooltip.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The same hint is available on hover and keyboard focus
- The tooltip contains no interactive control
- Escape closes it without moving focus
- Touch users are not denied essential information
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-tooltip
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Tooltip fix
# Prevent the Tooltip regression
## Objective
Turn the reproduced cause into a focused regression test and compare Tooltip with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Popover in your agent
## Objective
Implement Popover for this verified behavior: A small contextual surface opened deliberately to show supporting content or controls without making the whole page modal.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Popover matches the need before writing code.
## Required behavior
- Activating the trigger opens the surface, and activating it again can close it.
- A pointer press outside the noncritical surface dismisses it without committing an action.
- Escape closes the temporary surface and returns focus to a sensible control.
## States to cover
- Popover closed
- Popover open
## Accessibility
- ARIA role: dialog
- The primary control or named region for Popover has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Focus either remains on the trigger for simple content or moves predictably to the first meaningful control.
- Escape, the explicit close control, or a safe outside press closes it and restores focus to the trigger.
- The trigger exposes expanded state and references the popup; a named dialog is announced when that pattern is used.
- Enter or Space opens from the trigger
- Tab moves through interactive content
- Escape closes the popover
## When not to use
- The task needs a large or modal workflow
- The surface is only a short passive hint
## Acceptance criteria
- The panel opens only after deliberate activation
- Interactive content has a logical focus order
- Escape and the close control restore focus
- The background remains usable because the panel is nonmodal
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-popover
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Popover on a real journey
# Verify Popover after implementation
## Objective
Audit the Popover implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Popover in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Popover.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The panel opens only after deliberate activation
- Interactive content has a logical focus order
- Escape and the close control restore focus
- The background remains usable because the panel is nonmodal
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-popover
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Popover fix
# Prevent the Popover regression
## Objective
Turn the reproduced cause into a focused regression test and compare Popover with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Dropdown menu in your agent
## Objective
Implement Dropdown menu for this verified behavior: A compact list of actions that opens from a button and supports menu-style keyboard navigation.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Dropdown menu matches the need before writing code.
## Required behavior
- Activating the trigger opens the surface, and activating it again can close it.
- Arrow keys move through available actions while Enter or Space activates one.
- Escape closes the temporary surface and returns focus to a sensible control.
## States to cover
- Menu closed
- Menu open
## Accessibility
- ARIA role: menu > menuitem
- The primary control or named region for Dropdown menu has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Opening places menu focus on an enabled item; closing restores focus to the trigger.
- Selecting an action, pressing Escape, or safely pressing outside closes the menu.
- The trigger exposes that it opens a menu, and item names, disabled states, and checked states are announced.
- Enter, Space, or Arrow Down opens the menu
- Arrow keys move between items
- Enter or Space activates the active item
- Escape closes the menu
## When not to use
- The user is selecting a value for a form field
- The content contains explanatory paragraphs or a form
## Acceptance criteria
- Every item is an action rather than a form value
- Arrow-key navigation follows the menu pattern
- Disabled items expose their state and cannot be activated
- Closing restores focus to the trigger
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dropdown-menu
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Dropdown menu on a real journey
# Verify Dropdown menu after implementation
## Objective
Audit the Dropdown menu implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Dropdown menu in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Dropdown menu.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- Every item is an action rather than a form value
- Arrow-key navigation follows the menu pattern
- Disabled items expose their state and cannot be activated
- Closing restores focus to the trigger
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dropdown-menu
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Dropdown menu fix
# Prevent the Dropdown menu regression
## Objective
Turn the reproduced cause into a focused regression test and compare Dropdown menu with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Modal dialog in your agent
## Objective
Implement Modal dialog for this verified behavior: A focused surface for a contained task that makes the rest of the page temporarily inactive.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Modal dialog matches the need before writing code.
## Required behavior
- While modal, keyboard focus stays inside the surface until it closes.
- Escape closes the temporary surface and returns focus to a sensible control.
## States to cover
- Dialog closed
- Dialog open
## Accessibility
- ARIA role: dialog[aria-modal=true]
- The primary control or named region for Modal dialog has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Opening moves focus inside, Tab cannot reach the inert page, and closing restores focus to the logical opener.
- Cancel, the named close control, and Escape close without saving; outside press is enabled only when accidental loss is harmless.
- Assistive technology receives the dialog role, accessible title, description, and validation updates.
- Tab and Shift+Tab cycle inside the dialog
- Escape closes when cancellation is safe
- Enter submits only from the intended control
## When not to use
- The workflow is long enough to deserve its own page
- The information can remain nonmodal and contextual
## Acceptance criteria
- The page behind the dialog is inert
- The dialog has an accessible title and description
- Focus is contained and then restored
- Every dismissal path handles unsaved work safely
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dialog
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Modal dialog on a real journey
# Verify Modal dialog after implementation
## Objective
Audit the Modal dialog implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Modal dialog in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Modal dialog.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The page behind the dialog is inert
- The dialog has an accessible title and description
- Focus is contained and then restored
- Every dismissal path handles unsaved work safely
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dialog
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Modal dialog fix
# Prevent the Modal dialog regression
## Objective
Turn the reproduced cause into a focused regression test and compare Modal dialog with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Alert dialog in your agent
## Objective
Implement Alert dialog for this verified behavior: A modal dialog that interrupts a consequential action and requires an explicit confirm or cancel decision.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Alert dialog matches the need before writing code.
## Required behavior
- While modal, keyboard focus stays inside the surface until it closes.
- The surface remains until the user deliberately confirms or cancels the consequential action.
## States to cover
- Decision closed with workspace intact
- Initial deletion decision open
- Decision closed after cancellation
- Deletion decision reopened after cancellation
- Deletion submitting
- Decision closed after confirmed deletion
- Deletion decision reopened after confirmation
## Accessibility
- ARIA role: alertdialog[aria-modal=true]
- The primary control or named region for Alert dialog has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Initial focus lands on the least destructive useful action unless reading long consequences first is safer.
- Only an explicit decision or a documented safe cancellation closes the alert; no timer or accidental outside press dismisses it.
- The alert dialog role, title, consequence, and both action names are announced when focus enters.
- Tab moves only between decision controls
- Escape cancels when cancellation remains safe
- Enter activates the explicitly focused action
## When not to use
- The action can be safely undone
- The message only reports a result and needs no decision
## Acceptance criteria
- The message names the exact consequence
- Confirm and Cancel are explicit and visually distinct
- Initial focus avoids accidental destructive confirmation
- The alert cannot disappear before a decision
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-alert-dialog
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Alert dialog on a real journey
# Verify Alert dialog after implementation
## Objective
Audit the Alert dialog implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Alert dialog in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Alert dialog.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The message names the exact consequence
- Confirm and Cancel are explicit and visually distinct
- Initial focus avoids accidental destructive confirmation
- The alert cannot disappear before a decision
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-alert-dialog
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Alert dialog fix
# Prevent the Alert dialog regression
## Objective
Turn the reproduced cause into a focused regression test and compare Alert dialog with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Lightbox in your agent
## Objective
Implement Lightbox for this verified behavior: A modal viewer that enlarges one media item and may let the user move through a related collection.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Lightbox matches the need before writing code.
## Required behavior
- While modal, keyboard focus stays inside the surface until it closes.
- Previous and next controls move through the collection without leaving the viewer.
- Escape closes the temporary surface and returns focus to a sensible control.
## States to cover
- Gallery view
- Media expanded
## Accessibility
- ARIA role: dialog[aria-modal=true]
- The primary control or named region for Lightbox has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Opening moves focus to the viewer or close control, contains it, and closing returns it to the originating thumbnail.
- The named close control and Escape always dismiss; outside press is optional and never the only path.
- The viewer title, current item position, caption, image alternative text, and loading failures are available to assistive technology.
- Tab reaches viewer controls
- Left and Right move between media when documented
- Escape closes the viewer
## When not to use
- The media must be compared side by side
- The content is a form or consequential decision
## Acceptance criteria
- The selected media and its caption are clearly identified
- Keyboard users can reach navigation and close controls
- Focus returns to the originating thumbnail
- Loading and media errors have a textual fallback
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dialog
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Lightbox on a real journey
# Verify Lightbox after implementation
## Objective
Audit the Lightbox implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Lightbox in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Lightbox.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The selected media and its caption are clearly identified
- Keyboard users can reach navigation and close controls
- Focus returns to the originating thumbnail
- Loading and media errors have a textual fallback
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dialog
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Lightbox fix
# Prevent the Lightbox regression
## Objective
Turn the reproduced cause into a focused regression test and compare Lightbox with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Drawer in your agent
## Objective
Implement Drawer for this verified behavior: A temporary panel that slides from a viewport edge, overlays the page, and closes when its focused task is finished.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Drawer matches the need before writing code.
## Required behavior
- The temporary panel overlays the page and moves in from a defined viewport edge.
- While modal, keyboard focus stays inside the surface until it closes.
- Escape closes the temporary surface and returns focus to a sensible control.
## States to cover
- Drawer closed
- Drawer open
## Accessibility
- ARIA role: dialog[aria-modal=true]
- The primary control or named region for Drawer has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Opening places focus on the drawer heading or first useful field, contains it, and closing restores the opener.
- The named close control and Escape always work; backdrop dismissal is disabled when it could discard changes.
- The accessible title and optional description identify the drawer task as focus enters.
- Tab remains inside while open
- Escape closes without applying unintended changes
- Enter activates only the focused control
## When not to use
- The navigation must stay visible across pages
- The task needs the full viewport or several steps
## Acceptance criteria
- The panel is temporary and overlays the page
- Its edge and modal behavior are explicit
- Focus is contained and restored
- The narrow layout keeps every action reachable
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dialog
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Drawer on a real journey
# Verify Drawer after implementation
## Objective
Audit the Drawer implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Drawer in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Drawer.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The panel is temporary and overlays the page
- Its edge and modal behavior are explicit
- Focus is contained and restored
- The narrow layout keeps every action reachable
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@radix-ui/react-dialog
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Drawer fix
# Prevent the Drawer regression
## Objective
Turn the reproduced cause into a focused regression test and compare Drawer with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Bottom sheet in your agent
## Objective
Implement Bottom sheet for this verified behavior: A mobile-oriented surface attached to the bottom edge that can open to stable heights and may support dragging.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Bottom sheet matches the need before writing code.
## Required behavior
- Touch dragging moves the sheet between stable heights while controls remain keyboard operable.
- While modal, keyboard focus stays inside the surface until it closes.
- Escape closes the temporary surface and returns focus to a sensible control.
## States to cover
- Sheet closed
- Sheet at half height
- Sheet at full height
## Accessibility
- ARIA role: dialog[aria-modal=true]
- The primary control or named region for Bottom sheet has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Focus enters the modal sheet, remains inside, and returns to the Filters opener after closing.
- Close control, Escape, and a downward gesture past the documented threshold dismiss; accidental small drags snap back.
- The sheet title, current modal state, expanded state, and loading changes are available without relying on motion.
- Tab reaches all controls
- Buttons provide expand and collapse alternatives
- Escape closes the modal sheet
## When not to use
- Desktop side placement is the defining behavior
- Dragging is the only way to reach content or close
## Acceptance criteria
- The surface is visibly anchored to the bottom
- Every drag action has a button or keyboard equivalent
- Snap points reveal meaningful stable states
- Keyboard alternatives and focus restoration are verified
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
vaul
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Bottom sheet on a real journey
# Verify Bottom sheet after implementation
## Objective
Audit the Bottom sheet implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Bottom sheet in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Bottom sheet.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The surface is visibly anchored to the bottom
- Every drag action has a button or keyboard equivalent
- Snap points reveal meaningful stable states
- Keyboard alternatives and focus restoration are verified
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
vaul
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Bottom sheet fix
# Prevent the Bottom sheet regression
## Objective
Turn the reproduced cause into a focused regression test and compare Bottom sheet with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Sidebar in your agent
## Objective
Implement Sidebar for this verified behavior: A persistent region beside primary content that participates in page layout and usually contains navigation or supporting tools.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Sidebar matches the need before writing code.
## Required behavior
- The region occupies page layout space instead of temporarily covering primary content.
- If the product replaces the persistent region when space is insufficient, the replacement is a separately named temporary navigation control.
## States to cover
- Sidebar expanded
- Sidebar compact
## Accessibility
- ARIA role: aside > nav[aria-label]
- The primary control or named region for Sidebar has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- Focus moves normally between the sidebar and main content; collapse preserves a logical focused control.
- A persistent sidebar is collapsed, not dismissed; any temporary mobile counterpart follows its own Drawer dismissal contract.
- The navigation region has a unique name and the current destination uses aria-current when appropriate.
- Tab follows normal document order
- Enter activates links and collapse controls
- No focus trap is created
## When not to use
- The surface is needed only briefly
- The remaining content becomes too narrow or horizontally scrolls
## Acceptance criteria
- The sidebar occupies layout space rather than overlaying content
- Its navigation region has a unique name
- Current location and collapsed state are exposed
- The narrow-screen replacement is an explicit separate pattern
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
Web platform
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Sidebar on a real journey
# Verify Sidebar after implementation
## Objective
Audit the Sidebar implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Sidebar in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Sidebar.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- The sidebar occupies layout space rather than overlaying content
- Its navigation region has a unique name
- Current location and collapsed state are exposed
- The narrow-screen replacement is an explicit separate pattern
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
Web platform
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Sidebar fix
# Prevent the Sidebar regression
## Objective
Turn the reproduced cause into a focused regression test and compare Sidebar with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Select in your agent
## Objective
Implement Select for this verified behavior: A form control for choosing one or more values from predefined options without arbitrary text entry; a single-select commonly appears as a closed picker, while a multiple select may expose a list.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Select matches the need before writing code.
## Required behavior
- The control exposes whether one or multiple values can be selected and updates every selected state consistently.
- Arrow keys navigate according to the declared control model; focus and selection states are exposed consistently, including when selection follows focus.
## States to cover
- Single-select specimen collapsed
- Single-select specimen expanded
## Accessibility
- ARIA role: select
- The primary control or named region for Select has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- The native control delegates focus and option navigation to the platform for its declared single or multiple presentation.
- For a collapsed single-select, the platform picker closes using its standard commit or cancellation behavior; a list presentation does not imply a dismissible popup.
- Label, required state, selected value or values, disabled state, selection mode, and validation message are exposed by native semantics.
- Tab focuses the select
- Platform keys navigate the current single- or multiple-selection presentation
- The platform selection command updates the value or selected values
## When not to use
- Users need to search a long list
- Several options must remain visible for comparison
## Acceptance criteria
- A visible label names the value or values being chosen
- Only predefined values can be committed
- The single or multiple selection mode is explicit
- Required and error states are associated with the control
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
Web platform
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Select on a real journey
# Verify Select after implementation
## Objective
Audit the Select implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Select in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Select.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- A visible label names the value or values being chosen
- Only predefined values can be committed
- The single or multiple selection mode is explicit
- Required and error states are associated with the control
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
Web platform
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Select fix
# Prevent the Select regression
## Objective
Turn the reproduced cause into a focused regression test and compare Select with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Combobox in your agent
## Objective
Implement Combobox for this verified behavior: A value control with an associated popup; it can be editable or select-only, and the popup can be a listbox, grid, tree, or dialog.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Combobox matches the need before writing code.
## Required behavior
- The value control owns or controls an associated popup, exposes its expanded state and follows the keyboard model of the popup role.
- Escape closes the temporary surface and returns focus to a sensible control.
## States to cover
- Combobox idle
- Suggestions open
- City committed
## Accessibility
- ARIA role: combobox + popup (listbox | grid | tree | dialog)
- The primary control or named region for Combobox has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- In this editable listbox-popup specimen, DOM focus remains in the input while the active-option relationship communicates list navigation; other popup roles follow their own focus model.
- Escape closes an open popup without committing a new value; whether text is preserved and which other actions close it are defined by the combobox subtype.
- The combobox name, value, expanded state, popup relationship and relevant active or selected popup item are exposed; loading and result counts apply when the subtype provides them.
- In this editable listbox-popup specimen, typing edits the query
- Arrow Down and Up move the active option while focus remains in the input
- Enter commits the active option
- Escape closes suggestions without clearing text
## When not to use
- A short native Select is simpler
- No associated popup or disclosed assistance is needed
## Acceptance criteria
- Editable or select-only behavior is explicit
- The popup role and ownership relationship are explicit
- Focus and keyboard behavior match the popup role
- Escape closes the popup without committing a new value
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@base-ui/react
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Combobox on a real journey
# Verify Combobox after implementation
## Objective
Audit the Combobox implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Combobox in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Combobox.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- Editable or select-only behavior is explicit
- The popup role and ownership relationship are explicit
- Focus and keyboard behavior match the popup role
- Escape closes the popup without committing a new value
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
@base-ui/react
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Combobox fix
# Prevent the Combobox regression
## Objective
Turn the reproduced cause into a focused regression test and compare Combobox with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Implement Listbox in your agent
## Objective
Implement Listbox for this verified behavior: A composite widget of named options that supports one or multiple selections and can be standalone or used as a combobox popup.
## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Listbox matches the need before writing code.
## Required behavior
- Arrow keys navigate according to the declared control model; focus and selection states are exposed consistently, including when selection follows focus.
- The control exposes whether one or multiple values can be selected and updates every selected state consistently.
## States to cover
- Default preset selected
- Last 30 days selected
## Accessibility
- ARIA role: listbox > option
- The primary control or named region for Listbox has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- The native sized select is one tab stop. In this single-select specimen, selection follows keyboard focus, so active and selected state move together; custom listboxes must declare their own model.
- In this standalone specimen, leaving with Tab preserves the selected value; when a listbox is a popup, dismissal is coordinated by its owning control.
- The list name, four-option count, selected state, disabled state, and this specimen's single-selection mode are exposed by native semantics.
- Tab enters the composite control once
- In this native single-select specimen, arrow navigation updates selection as focus moves
- There is no separate commit command in this specimen
- Platform-supported Home and End keys reach boundaries
## When not to use
- Screen space is scarce and a native Select is sufficient
- Items are commands instead of values
## Acceptance criteria
- Options belong to one named list, whether standalone or used as a popup
- The relationship between focus and selection is declared, including whether selection follows focus
- Arrow, Home, and End behavior is consistent
- The selection mode is explicit
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
Web platform
Requires · Access to the repository, design system, and tests
Why it works
The need is tied to canonical behavior before any technical choice.
States, accessibility, and non-goals prevent a merely visual implementation.
Acceptance criteria and the output format make verification observable.
Try next
Verify Listbox on a real journey
# Verify Listbox after implementation
## Objective
Audit the Listbox implementation against its behavior, states, and accessibility requirements without changing it automatically.
## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
# Debug Listbox in your agent
## Observed symptom
[DESCRIBE THE SYMPTOM HERE]
## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Listbox.
- Verify keyboard behavior, focus, accessible name, and announcements.
## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.
## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.
## Final verification
- Options belong to one named list, whether standalone or used as a popup
- The relationship between focus and selection is declared, including whether selection follows focus
- Arrow, Home, and End behavior is consistent
- The selection mode is explicit
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
Web platform
Requires · Access to the repository, design system, and tests
Why it works
The explicit symptom prevents starting from an assumed fix.
Checks separate behavior, accessibility, and neighboring interference.
The fix stays bounded and must produce regression evidence.
Try next
Lock in the Listbox fix
# Prevent the Listbox regression
## Objective
Turn the reproduced cause into a focused regression test and compare Listbox with neighboring concepts before widening the fix.
## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.
## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.
## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.
