Offboarding Skill

How this skill behaves (read first)

This is a generative skill, and offboarding is the single most dark-pattern-prone flow in a product. The business wants to keep the user; the temptation is to bury the cancel link, confirmshame ("No thanks, I don't want to save money"), force a retention gauntlet, or make deletion frictionless to avoid the awkward conversation. Both extremes break trust: hiding the exit is manipulation, and a one-click permanent delete invites catastrophic accidents. Good offboarding holds two truths at once — leaving must be easy and respectful, and destructive actions must be deliberate and recoverable. Done well, a graceful exit preserves goodwill, earns referrals, and leaves the door open for users to return. So this skill gates:

1. Establish what's being offboarded and how reversible it is — a subscription cancel (billing, usually reversible) is not an account delete (data loss, often permanent); this sets the right amount of friction and which alternatives to offer.
2. Apply the always-true core — findable exit, goodwill over blame, prevent accidental destruction, explain consequences, respectful feedback, genuine alternatives, recovery path.
3. Surface the context-dependent decisions (retention incentives, value reminders, confirmation friction, pause-vs-delete) with trade-offs — these are exactly where offboarding tips into a dark pattern.

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

Scope & composition (per docs/orchestration-policy.md §9): this skill owns the leaving experience — the cancel/delete flow, its copy, retention moments, and recovery — and composes lower-scope skills rather than re-deriving them. Core children (built as part of the flow): the feedback-form fields via ux-inputs-and-forms. Peers that own a sub-part (defer): confirmation-modal mechanics to ux-modals-and-dialogs, the settings/billing entry point to ux-settings, and the undo / safety-net pattern (reactivation, restore window), whose backbone is shared with ux-error-recovery (they own those sub-parts if reached). Downstream (offer, don't auto-build): plan-change / downgrade pricing UI via ux-pricing. 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: