Error Recovery Skill

How this skill behaves (read first)

This is a generative skill. Claude's default error handling is the failure mode: it writes "Something went wrong," validates only on submit, blames the user ("You entered an invalid value"), treats every error at the same severity, shouts in ALL CAPS or leaks codes ("Error 403: Forbidden"), offers no way back from a 404, and never thinks about preventing the error in the first place. Good error recovery inverts that. Its first move is to prevent errors (most are designable away with constraints, masks, and defaults), then make the unavoidable ones recoverable — tell the user what happened and what to do next, give them a safety net, and never leave a dead end. So this skill gates:

1. Establish stakes, error source, and where in the journey the error happens — these decide how much friction, confirmation, and escalation is warranted.
2. Apply the always-true core — prevent first, validate without interrupting, write recoverable messages, give a safety net, never dead-end.
3. Surface the context-dependent decisions (confirm vs. undo, validation timing, humor, AI degradation/confidence, transparency vs. security) with trade-offs.

Then it hands off to ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, ux-microcopy-audit, ux-dark-patterns-audit, and (when mobile) ux-mobile-responsiveness-audit for validation.

Scope & composition (per docs/orchestration-policy.md §9): this skill owns the error/failure/recovery experience — error states, message craft, validation behavior, undo/confirmation, degradation, and error pages — and composes lower-scope skills rather than re-deriving them. Core children (built as part of the recovery experience): input-field anatomy via ux-inputs-and-forms. Peers that own a sub-part (defer): toast/notification type & frequency to ux-notifications-and-toasts and confirmation-modal mechanics to ux-modals-and-dialogs (they own those sub-parts if reached). Downstream (offer, don't auto-build): first-use / no-results / cleared empty screens via ux-empty-states, the password-reset flow via ux-login-signup, save-state confirmation via ux-settings, and help/contact at the point of error via ux-contact-support. Inherit, don't regenerate: under an existing design system, take color/type/spacing from its tokens — only set those when designing from scratch.

Step 0 — Establish context before designing

Ask if not known; state the assumption if proceeding without an answer: