skills/recovery-app-onboarding/SKILL.md
Expert guidance for designing and implementing onboarding flows in recovery, wellness, and mental health applications. This skill should be used when building onboarding experiences, first-time user flows, feature discovery, or tutorial systems for apps serving vulnerable populations (addiction recovery, mental health, wellness). Activate on "onboarding", "first-time user", "tutorial", "feature tour", "welcome flow", "new user experience", "app introduction", "recovery app UX". NOT for general mobile UX (use mobile-ux-optimizer), marketing landing pages (use web-design-expert), or native app development (use iOS/Android skills).
npx skillsauth add curiositech/windags-skills recovery-app-onboardingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Build compassionate, effective onboarding experiences for recovery and wellness applications that serve vulnerable populations with dignity and practical utility.
Navigate onboarding design through these critical decision trees:
Is user in crisis?
├── YES → Skip to crisis resources immediately
│ └── Offer lightweight onboarding after crisis resolved
└── NO → Continue to value demonstration
User engagement level?
├── HIGH (opened app 3+ times) → Skip basic intro, show advanced features
├── MEDIUM (opened 1-2 times) → Standard onboarding flow
└── LOW (first time) → Value-first approach, minimal friction
User wants to skip current step?
├── Essential step (safety/crisis)?
│ ├── YES → Show "Quick Setup" alternative (30 sec version)
│ └── NO → Block skip, explain importance briefly
└── Optional step?
├── Mark as skipped, offer in-app discovery later
└── Continue to next essential step
Has user completed any onboarding before?
├── YES → Jump to step after last completed
├── PARTIAL → Resume from last incomplete essential step
└── NO → Start from welcome
Feature requires permission?
├── Location for meetings → Show value first ("Find meetings near you"), then prime
├── Notifications for reminders → After user sets first goal/appointment
├── Camera for progress photos → Only when user opens that feature
└── Contacts for emergency → During safety planning (optional step)
User denied permission?
├── Offer alternative (ZIP search vs location)
├── Explain impact clearly ("You'll need to search manually")
└── Don't ask again for 30 days unless user initiates
Symptoms: Users skip all steps rapidly, don't engage with core features Detection: >80% skip rate OR completion time <2 minutes for full flow Fix: Add micro-value demonstrations between steps, make skipping require explanation of alternatives
Symptoms: High drop-off rate after welcome screen, users don't return Detection: <24hr retention <40% AND no crisis resource access logged Fix: Crisis detection questions on step 1, immediate resource access, defer non-essential onboarding
Symptoms: Users grant no permissions, app functionality severely limited Detection: Permission grant rate <30% AND feature usage <20% of potential Fix: Contextual priming before each request, show specific value, provide fallback options
Symptoms: Users feel overwhelmed by feature list, abandon mid-flow Detection: Drop-off spikes at feature showcase step (>40% exit rate) Fix: Limit to 3 essential features only, use progressive disclosure for advanced features
Symptoms: Users concerned about anonymity, don't create accounts Detection: <50% account creation rate AND high exit at data entry steps Fix: Lead with anonymity messaging, show data handling practices, offer guest mode
Scenario: First-time user, evening access, appears stable (not crisis state)
Onboarding completion criteria - all must pass:
[ ] Crisis resources accessible from every onboarding screen [ ] Entire flow completable in under 3 minutes [ ] All steps skippable except crisis resource acknowledgment [ ] Works offline after initial download [ ] Screen reader announces step changes with aria-live [ ] Touch targets minimum 44x44px on all interactive elements [ ] Color contrast 4.5:1 ratio for all text under 18px [ ] Completion time tracked and logged for optimization [ ] Permission requests include contextual value explanation [ ] Recovery program selection allows multiple choices [ ] Emergency contact setup clearly marked optional [ ] Feature discovery continues post-onboarding via tooltips [ ] User can return to onboarding from settings [ ] Progress persists across app sessions [ ] Crisis path validation: can reach resources in <10 seconds from any step
This skill should NOT be used for:
mobile-ux-optimizer insteadconversion-optimization insteadproduct-onboarding insteadweb-design-expert insteadsupabase-admin insteadauth-security insteadDelegation patterns:
web-design-expertaccessibility-experttools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.