skills/recovery-app-legal-terms/SKILL.md
Generate legally-sound terms of service, privacy policies, and medical disclaimers for recovery and wellness applications. Expert in HIPAA, GDPR, CCPA compliance. Activate on 'terms of service', 'privacy policy', 'legal terms', 'medical disclaimer', 'HIPAA', 'user agreement'. NOT for contract negotiation (use attorney), app development (use domain skills), or moderation (use recovery-community-moderator).
npx skillsauth add curiositech/windags-skills recovery-app-legal-termsInstall 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.
Generate legally-sound terms of service, privacy policies, and medical disclaimers for recovery and wellness applications that protect users while maintaining supportive, non-stigmatizing language.
Is user data processing?
├─ YES: What type of processing?
│ ├─ Service delivery (account, progress tracking)
│ │ └─ USE: Contract performance (Art 6.1b)
│ ├─ Analytics, improvements, marketing
│ │ ├─ High privacy impact?
│ │ │ ├─ YES → USE: Explicit consent (Art 6.1a)
│ │ │ └─ NO → USE: Legitimate interest (Art 6.1f)
│ │ └─ INCLUDE: Opt-out mechanism
│ └─ Health/recovery data (special category)
│ └─ USE: Explicit consent (Art 9.2a) + health exception (Art 9.2h)
└─ NO: No legal basis needed
Does app provide any of these?
├─ Progress tracking, sobriety counters → Include "not medical advice"
├─ Peer support, community features → Include "not therapy/counseling"
├─ Motivational content, tips → Include "consult healthcare providers"
├─ Crisis language detection → MUST include 988 hotline reference
└─ Any recovery-related features → Include "no recovery guarantees"
Age verification needed?
├─ Under 13 allowed → COPPA compliance required
├─ 13-17 allowed → Parental consent mechanism
└─ 18+ only → Simple age verification sufficient
What type of data?
├─ Account/profile data
│ └─ Retention: Until deletion requested or 6 years inactive
├─ Health/recovery progress
│ └─ Retention: User controlled + legal minimums (2-7 years)
├─ Community posts/messages
│ └─ Retention: User controlled, immediate deletion option
└─ Usage analytics
└─ Retention: Aggregate after 90 days, delete identifiers
Scenario: App tracks sobriety streaks, allows photo journals, has peer support chat
Decision Process:
Expert catches: Health data sharing with sponsors/counselors needs explicit opt-in Novice misses: Treating all data the same, missing special category health protections
Key sections generated:
## What Information We Collect
- Account info (email, username) - needed to provide service
- Sobriety progress (days sober, milestones) - you control sharing
- Chat messages - support community features, auto-delete after 1 year
Do NOT use this skill for:
Delegate when:
data-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.