Demo data and a fast laptop hide the states real users meet on day one: slow networks, empty accounts, failed requests, expired sessions. AI-built UIs usually implement only the happy path.

This skill is self-contained. Its companions (declared in its metadata) are skills whose method it may need to do its own promised work. Use of a companion can be conditional: declaring one does not mean running it. When a companion's lane applies, use the skill if it is installed; if not, follow its short entry in references/companion-methods.md and say in your report which lanes ran inline at reduced depth. Never skip an applicable lane silently. Skills mentioned here only for escalation, referral, documentation, or optional deeper follow-up are not dependencies: report the hand-off and finish honestly.

Companions: .

1. Enumerate the data-dependent views and actions from routes and components: lists, dashboards, detail pages, search, forms, uploads, payments, auth transitions.

[]

undefined

3. Force the failures (local/staging only). The runtime helper can fail, slow, and cut the network (paths relative to this skill's folder):

node scripts/observe-runtime.mjs --url <site> --fail "**/api/items=500"            # server error
node scripts/observe-runtime.mjs --url <site> --fail "**/api/items=abort"          # network failure
node scripts/observe-runtime.mjs --url <site> --fail "**/api/items=401" --steps s.json   # expired session
node scripts/observe-runtime.mjs --url <site> --delay "**/api/items=6000" --screenshots ./shots --steps s.json

Steps can , , , and to lose the network mid-flow. Screenshots let you see the loading, empty, and error states; and show what the page logged. Also try an empty list (serve ) by pointing at a staging backend or a stub. Watch for: spinner forever; blank white screen; console errors with no UI; success toast after a failed request; data disappearing; infinite retry loops.

4. Code patterns: that only s; ; loading flags never reset in ; missing error boundaries (React) or /; optional chaining hiding renders; without fallback; unhandled promise rejections; lists rendering on possibly-undefined data.

5. Auth and session transitions: expired token mid-action; logged-out user hits a private URL (redirect vs error); post-login return path.

6. Error copy honesty: no fake success, no "Something went wrong" with no route forward when a retry or support link is available.

Label each claim OBSERVED, SOURCE-INDICATED, DECLARED, INFERRED, UNKNOWN, or REVIEW REQUIRED. UNKNOWN is never a pass and never a failure.

Design first. Before creating or changing anything visible, inspect the project's existing design system () and build from its tokens and components, by the component ladder: reuse, compose, extend, and only then create a matching component. Never impose a ReadyVibe look on the user's site.

Add or fix loading, empty, error, and success states in the existing design system; add resets; add error boundaries and route-level error pages; preserve form input on failure; add retry affordances; add timeouts where the pattern exists. Do not add global fake success, hide errors, or over-engineer retry/backoff frameworks.

"Resilient", "handles all failures", or "production-ready error handling". State which failure classes you forced.

Repeat each forced failure after changes: the UI shows a clear message, offers recovery, recovers when the failure ends, and nothing logs uncaught errors. Confirm the happy path still works.

Payment or auth flows whose failure states you cannot test safely; data-loss risks (unsaved work on error); offline-first expectations (a product decision).

Views already handle the five states, or the site has no data-dependent UI. Do not add skeletons to a static page.