Act as a senior front-end engineer. Add loading skeletons to {{page_or_feature}} in my {{tech_stack}} project. Read the components and data fetching first, and list every place that shows a spinner, blank space or jump while loading. Match the final layout exactly: - Same container sizes, padding, gaps and grid columns at 360, 768 and 1280px - Text as bars the height of the real line height, the last line shorter; headings one bar, body 2 or 3 - Images and avatars as boxes with the real aspect ratio and radius - The expected number of items, such as 6 cards, not 1 or 20 - Built from the same layout components as the real content, so they can't drift apart Timing and motion: - Show a skeleton only if loading takes over 200ms; once shown, keep it at least 400ms so it doesn't flash - Shimmer: a soft highlight sliding across with transform, 1.6s linear, looping; or static blocks. Never brighter than one step above the surface color - Real content fades in over 150ms, ease-out - Under prefers-reduced-motion: reduce, no shimmer, static blocks only Accessibility: aria-busy on the loading region, one visually hidden Loading status message, and skeleton shapes hidden from screen readers. Every state at the same size: loading, loaded, empty with a helpful next step, and error with a retry button. Performance budget: layout shift of 0 when content arrives, shimmer on the compositor only, and no skeleton for cached data that appears in under 200ms. Avoid: skeletons that look nothing like the result, full-page spinners, and skeleton buttons; buttons show their own loading state. Finish with before-and-after layout shift numbers and the files changed.