Implement correctly
Build Skeleton without breaking its behavior
# Implement Skeleton in your agent ## Objective Implement Skeleton for this verified behavior: Decorative placeholder shapes that reserve the approximate layout of content while that content is loading. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Skeleton matches the need before writing code. ## Required behavior - Placeholder shapes reserve stable space and are replaced by real content without a layout jump. - The content region exposes its busy state while a separate visual indicator remains redundant. ## States to cover - Placeholders visible - Content visible - Failed card error visible ## Accessibility - ARIA role: [aria-hidden=true] + [aria-busy=true] - The primary control or named region for Skeleton has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Focus remains on the existing page; replacing placeholders does not reorder or steal focus. - Skeletons disappear only when replaced by content, an empty state, or an actionable error state. - The region announces a concise loading state and final result; individual decorative shapes are never announced. - Placeholders never enter the tab order - Retry controls appear only in real error states ## When not to use - The wait concerns one compact button action - The final layout is unknown or highly variable ## Acceptance criteria - Placeholder geometry approximates final content - Skeleton shapes are hidden from assistive technology - The parent region exposes busy state - Empty and error states replace an indefinite wait ## 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 Skeleton on a real journey
# Verify Skeleton after implementation ## Objective Audit the Skeleton 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:79b04d3188656c3c622b4c23a0dfa99a27dee8dfe44b3e5d8223ea73be22b91e