Implement correctly
Build Pagination without breaking its behavior
# Implement Pagination in your agent ## Objective Implement Pagination for this verified behavior: A set of navigation links that moves among peer pages of one content collection split by quantity. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Pagination matches the need before writing code. ## Required behavior - A page, Previous, or Next link loads another quantity-based slice of the same collection. - Pointer, touch, or Enter follows the link; Space keeps its native page-scrolling behavior. ## States to cover - Page 1 - Page 2 - Page 3 ## Accessibility - ARIA role: nav[aria-label] > ul > li > a[aria-current=page] - The primary control or named region for Pagination has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Native navigation follows browser behavior; an in-place result update moves focus to the results heading or announces the new page consistently. - Pagination is persistent navigation and is not dismissible. - Label numeric destinations as Page N, mark exactly one current page, and keep range gaps noninteractive. - Tab and Shift+Tab visit available links - Enter activates the focused destination - Ellipses never receive focus ## When not to use - Sections differ by meaning or workflow stage - Continuous loading is essential and page destinations do not exist ## Acceptance criteria - The navigation landmark is named - Every available page has a real href - Exactly one link has aria-current=page - Ellipses are not controls - In-place updates manage focus or announce context ## 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 Pagination on a real journey
# Verify Pagination after implementation ## Objective Audit the Pagination 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.
sha256:1ed0302d69d57027278be188c2ebd299470857a6cc76a07837c2381729612a2e