agy-superpowers 5.2.2 → 5.2.3

package/template/agent/skills/data-analyst/SKILL.md

@@ -1,147 +0,0 @@
----
-name: data-analyst
-description: Use when setting up metrics frameworks, analyzing funnels, running cohort analysis, designing dashboards, or evaluating A/B test results
----
-
-# Data Analyst Lens
-
-> **Philosophy:** If you can't measure it, you can't improve it — but measuring the wrong thing is worse than measuring nothing.
-> Good data asks better questions. It rarely answers them alone.
-
----
-
-## Core Instincts
-
-- **North Star Metric first** — one metric that best captures value delivered to users
-- **Correlation ≠ causation** — always ask "what else changed?" before attributing a result
-- **Segment always** — averages hide everything; cohort and segment data reveals reality
-- **Lagging vs leading indicators** — revenue is lagging (past); activation is leading (predicts future)
-- **Statistical significance is a bar, not a target** — p < 0.05 means 1 in 20 tests will false-positive
-
----
-
-## North Star Metric Selection
-
-| Product Type | Example North Star Metric |
-|-------------|--------------------------|
-| Productivity / Utility | Tasks completed per week |
-| Health / Fitness | Workouts logged per month |
-| Social | Messages sent per DAU |
-| E-commerce | Revenue per monthly visitor |
-| SaaS / B2B | Weekly active seats |
-| Mobile subscription | D30 retained paying users |
-
-**NSM must:** correlate with revenue, be measurable weekly, be understandable by the whole team.
-
----
-
-## Standard Metrics Framework
-
-```
-Acquisition:  CAC, installs, signups, traffic source breakdown
-Activation:   Activation rate, time-to-aha-moment, onboarding completion %
-Retention:    D1/D7/D30 retention, DAU/MAU ratio, session frequency
-Revenue:      MRR, ARR, ARPU, LTV, churn rate (voluntary + involuntary)
-Referral:     Viral coefficient K, NPS, referral program conversion
-```
-
-**DAU/MAU ratio** = engagement quality indicator:
-- > 50% = highly engaging (social / gaming)
-- 20–40% = good (productivity tools)
-- < 10% = low engagement / retention problem
-
----
-
-## A/B Test Significance
-
-| Metric | Requirement |
-|--------|-------------|
-| Sample size per variant | ≥ 1,000 (for conversion rates) |
-| Minimum test duration | 2 weeks (captures weekly patterns) |
-| Statistical significance | p < 0.05 (95% confidence) |
-| Practical significance | Δ > 5% (otherwise not actionable) |
-| Type I error risk | 5% — 1 in 20 "significant" results is false positive |
-| Type II error | Run power analysis before test (sample size calculator) |
-
-**Never stop a test early** — stopping when significance is first reached inflates Type I error rate.
-
----
-
-## Cohort Analysis Interpretation
-
-```
-Week 0 cohort: users who signed up in week 0
-Retention at Day 30 = % of week 0 cohort still active on day 30
-
-Healthy retention curve: steep drop Day 0→7, then flattens (users who stay, stay)
-Unhealthy curve: no flattening, continues declining → no core retained audience
-```
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Report averages only | Averages hide bimodal distributions | Report medians + percentiles (p50, p90, p99) |
-| Declare test winner before reaching significance | False positive — winner may be noise | Predetermined sample size + duration |
-| Track everything, focus on nothing | Data overload → analysis paralysis | 3–5 top metrics per team |
-| Compare dissimilar cohorts | Apples vs oranges | Cohort by signup date, not current period |
-| Attribute all growth to last-click | Multi-touch attribution required | Use first-touch + last-touch + time-decay models |
-| Ignore data quality | Garbage in, garbage out | Instrument → validate → trust |
-
----
-
-## Questions You Always Ask
-
-**When setting up metrics:**
-- What is the North Star Metric, and how often can we measure it?
-- Is this a leading or lagging indicator?
-- How will data be collected — are there gaps in instrumentation?
-
-**When analyzing a result:**
-- Is the sample size large enough for significance?
-- Could a confounding variable explain this change?
-- Does the result hold when segmented by cohort/device/acquisition source?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] No North Star Metric defined
-- [ ] A/B tests declared significant before reaching 1,000 per variant
-- [ ] No event tracking on key activation events
-- [ ] Reporting only total signups / installs (not activated users)
-
-**Should fix:**
-- [ ] No cohort retention analysis (only aggregate retention)
-- [ ] All metrics reported as averages (no percentiles)
-- [ ] Dashboard not reviewed in weekly team ritual
-
----
-
-## Who to Pair With
-- `growth-hacker` — for AARRR funnel analysis and experiment design
-- `product-manager` — for North Star Metric definition and outcome tracking
-- `retention-specialist` — for retention curve and churn cohort analysis
-
----
-
-## Key Formulas
-
-```
-MRR              = paying_users × ARPU
-ARR              = MRR × 12
-LTV              = ARPU / monthly_churn_rate
-CAC              = total_acquisition_spend / new_customers
-LTV:CAC ratio    ≥ 3:1
-DAU/MAU ratio    = (DAU / MAU) × 100%
-Viral coeff. K   = invites_per_user × invite_conversion_rate
-Monthly churn    = churned_this_month / users_start_of_month
-```
-
----
-
-## Tools
-Mixpanel · Amplitude · PostHog (self-hosted) · Metabase · Google Looker Studio · Statsig / LaunchDarkly (experiment platform) · Segment (data pipeline) · BigQuery / Redshift (data warehouse)

package/template/agent/skills/devops-engineer/SKILL.md

@@ -1,117 +0,0 @@
----
-name: devops-engineer
-description: Use when working on CI/CD pipelines, infrastructure, deployment, monitoring, or reliability engineering — regardless of cloud provider
----
-
-# DevOps Engineer Lens
-
-> **Philosophy:** Automate everything deployable. Observe everything running. Fail safely, recover fast.
-> If it's not in version control, it doesn't exist. If it's not monitored, it will fail silently.
-
----
-
-## ⚠️ ASK BEFORE ASSUMING
-
-| What | Why it matters |
-|------|----------------|
-| **Cloud provider?** AWS / GCP / Azure / Fly / Railway | Determines services and tooling |
-| **Team size?** Solo / small team | Determines complexity vs value trade-offs |
-| **Current deploy process?** Manual / CI/CD | Determines where to start |
-| **SLO requirements?** 99.9% / 99.99% | Drives infrastructure decisions |
-
-When unspecified, assume small team + Docker + GitHub Actions + managed cloud (Railway/Fly/Render).
-
----
-
-## Core Instincts
-
-- **Immutable infrastructure** — never SSH to patch production; redeploy instead
-- **Observability-first** — logs, metrics, traces before adding features
-- **Fail fast, recover faster** — MTTR matters more than MTBF for indie hackers
-- **Automate the deploy path** — every manual step is a future incident waiting to happen
-- **Secrets are not config** — credentials never live in code or environment variables baked into images
-
----
-
-## Reliability Thresholds
-
-| SLO | Allowed downtime/month | Allowed downtime/year |
-|-----|----------------------|----------------------|
-| 99% | 7.3 hours | 3.65 days |
-| 99.5% | 3.6 hours | 1.83 days |
-| **99.9%** | **43 minutes** | **8.7 hours** |
-| 99.95% | 21 minutes | 4.4 hours |
-| 99.99% | 4.3 minutes | 52 minutes |
-
-**For indie hackers:** 99.9% is the right target. 99.99% requires significant investment — only worth it when downtime costs > infra cost.
-
-**Key metrics:**
-- **MTTR** (Mean Time to Recovery): target < 15min for P1 incidents
-- **MTBF** (Mean Time Between Failures): track over rolling 30 days
-- **Deploy frequency**: healthy = multiple times/day; red flag = < once/week
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Deploy directly from local machine | "Works on my machine" incidents, no audit trail | CI/CD pipeline always |
-| No staging environment | Production = first time bugs are discovered | Staging that mirrors prod |
-| Secrets in `.env` committed to git | One git history leak = all creds compromised | Doppler / AWS Secrets Manager / Vault |
-| Long-lived feature branches | Merge conflicts, integration hell | Trunk-based dev + feature flags |
-| No rollback plan | Bad deploy = extended outage | Blue-green or canary + 1-click rollback |
-| Alerts on everything | Alert fatigue = ignored alerts | Page only on SLO breaches, not symptoms |
-| Manual database migrations | Easy to forget, easy to run wrong order | Migration runner in deploy pipeline |
-
----
-
-## Questions You Always Ask
-
-**When designing infrastructure:**
-- What's the rollback plan if this deploy goes wrong?
-- What does a 10x traffic spike do to this setup?
-- How long does a full restore from backup take?
-- Who gets paged when this fails at 3am?
-
-**When reviewing CI/CD:**
-- Does every PR get tested before merge?
-- Are secrets injected at runtime, not baked into images?
-- Is the deploy pipeline idempotent (safe to re-run)?
-
----
-
-## Red Flags in Code Review / Infrastructure Review
-
-**Must fix:**
-- [ ] Secrets in source code, Dockerfiles, or `.env` committed to repo
-- [ ] No health check endpoint on services
-- [ ] No automated tests in CI pipeline
-- [ ] Manual production deploys with no audit trail
-
-**Should fix:**
-- [ ] No staging environment (or staging diverged from prod)
-- [ ] Database backups untested (backup ≠ restore test)
-- [ ] Alerts firing on every error (not SLO-based)
-- [ ] Single point of failure with no redundancy
-
----
-
-## Who to Pair With
-- `backend-developer` — for deployment architecture of APIs
-- `data-analyst` — for metrics pipeline and observability stack
-- `cto-architect` — for scaling decisions and infrastructure design
-
----
-
-## Tool Reference
-
-| Category | Tools |
-|----------|-------|
-| CI/CD | GitHub Actions, GitLab CI, CircleCI |
-| Container | Docker, Kubernetes (k8s when you have a team), Fly.io, Railway |
-| Secrets management | Doppler, AWS Secrets Manager, 1Password Secrets |
-| Monitoring | Datadog, Grafana + Prometheus, Better Uptime |
-| Error tracking | Sentry, Bugsnag |
-| Logging | Papertrail, Logtail, CloudWatch |
-| IaC | Terraform, Pulumi (for teams), SST (for AWS serverless) |

package/template/agent/skills/email-infrastructure/SKILL.md

@@ -1,164 +0,0 @@
----
-name: email-infrastructure
-description: Use when setting up transactional email, managing deliverability, configuring SPF/DKIM/DMARC, building email templates, or debugging email delivery issues
----
-
-# Email Infrastructure Lens
-
-> **Philosophy:** Deliverability is a reputation game. One spam complaint can blacklist your domain for weeks.
-> Transactional email is infrastructure — it must be reliable, observable, and tenant-isolated.
-
----
-
-## Core Instincts
-
-- **Domain reputation is fragile** — separate transactional from marketing; don't let bulk mail ruin auth emails
-- **Sending ≠ delivering** — always verify delivery via bounce/open tracking and suppression lists
-- **Never send from your root domain** — use a subdomain (`mail.yourdomain.com`) to protect your primary domain's reputation
-- **Warm up new IPs/domains** — cold domains go to spam; ramp gradually
-- **Unsubscribes are legal obligations** — CAN-SPAM, GDPR require easy opt-out
-
----
-
-## Email Type Separation
-
-| Type | Examples | Volume | Sender domain | Provider pool |
-|------|----------|--------|---------------|--------------|
-| **Transactional** | Password reset, invoice, welcome | Low | `mail.yourdomain.com` | Dedicated / transactional |
-| **Lifecycle / product** | Trial ending, usage nudges | Medium | `mail.yourdomain.com` | Dedicated / transactional |
-| **Marketing / newsletters** | Product updates, promotions | High | `newsletter.yourdomain.com` | Separate / marketing |
-
-❗ **Critical:** Marketing and transactional must use separate sending pools. A spam complaint on a newsletter should never affect password reset delivery.
-
----
-
-## DNS Authentication (Must Have)
-
-```
-SPF (Sender Policy Framework)
-  → Declares which IPs are allowed to send email from your domain
-  → Add to DNS: TXT record on yourdomain.com
-  → Example: "v=spf1 include:sendgrid.net include:resend.com ~all"
-  → Max 10 DNS lookups (hard limit); use flattening tools if exceeded
-
-DKIM (DomainKeys Identified Mail)
-  → Cryptographic signature proving email wasn't tampered with
-  → Your ESP generates CNAME records; add to DNS
-  → Check: "selector._domainkey.yourdomain.com"
-
-DMARC (Domain-based Message Authentication)
-  → Policy: what to do with emails that fail SPF/DKIM
-  → Start: p=none (monitor) → move to p=quarantine → p=reject
-  → Add: _dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"
-  → DMARC aggregate reports tell you who's failing and why
-
-Required order: SPF → DKIM → DMARC
-Without all three: Google/Yahoo bulk sender requirements (2024) → emails rejected
-```
-
----
-
-## Deliverability Rules
-
-| Rule | Why |
-|------|-----|
-| Spam complaint rate < **0.08%** | Google/Yahoo threshold; above = Gmail blocks |
-| Hard bounce rate < **2%** | Remove bounced emails immediately |
-| List hygiene: unverified emails | Never send to addresses that haven't confirmed |
-| Unsubscribe link required | CAN-SPAM (US) + GDPR (EU) legal requirement |
-| One-click unsubscribe (RFC 8058) | Gmail requires for bulk senders (> 5K/day) |
-| Text version alongside HTML | Many spam filters penalize HTML-only |
-
----
-
-## Email Queue Architecture
-
-```
-❌ NEVER send email synchronously in request handler:
-  POST /reset-password → send email → respond
-
-✅ Queue email jobs:
-  POST /reset-password → create job in queue → respond 200
-                                ↓ (async)
-                         Worker picks up job → send via ESP → log result
-
-Why: Email sending can take 1–3 seconds; timeouts → duplicate sends → user frustration
-Queue retry: 3 attempts with exponential backoff (1s, 5s, 30s)
-```
-
----
-
-## Template Best Practices
-
-```
-Structure:
-- Max width: 600px (renders correctly in all clients)
-- Always include plaintext alternative
-- Inline CSS only (Gmail strips <style> blocks)
-- Images: always include alt text; assume images are blocked
-- CTA button: use table-based HTML (VML for Outlook)
-
-Testing:
-- Litmus / Email on Acid for client rendering
-- SpamAssassin score < 2 (most spam filters use SA)
-- Check: mail-tester.com (free quick test)
-```
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Send from root domain | Spam complaints = root domain blacklisted | Use `mail.yourdomain.com` subdomain |
-| Marketing + transactional same pool | Marketing spam rates kill auth email delivery | Separate sender pools |
-| No SPF/DKIM/DMARC | Emails rejected by Gmail/Yahoo (2024 policy) | Configure all three before launch |
-| Retry email without checking bounces | Sending to bounced emails = reputation damage | Remove hard bounces immediately |
-| Suppress all email on one unsubscribe | User unsubscribes from marketing, loses auth emails | Separate marketing vs transactional opt-out lists |
-| Send email synchronously in API handler | Timeouts → duplicate sends → user sees email twice | Job queue always |
-
----
-
-## Questions You Always Ask
-
-**When setting up email:**
-- Are SPF, DKIM, and DMARC configured? (Check: `mxtoolbox.com`)
-- Are transactional and marketing emails on separate sending pools?
-- Is email sending queued (not synchronous in the request)?
-- What happens when an email bounces? Is the address suppressed?
-
-**When debugging delivery issues:**
-- What does the ESP delivery log show? Was it accepted or rejected?
-- Is the DMARC report showing authentication failures?
-- What's the spam complaint rate this week?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] No DKIM/SPF/DMARC configured (emails fail Gmail/Yahoo)
-- [ ] Transactional and marketing sent from same pool
-- [ ] Bounced addresses not being suppressed
-- [ ] Email sent synchronously in request handler
-
-**Should fix:**
-- [ ] No plaintext version of HTML emails
-- [ ] No DMARC report monitoring
-- [ ] Unsubscribe doesn't work within 10 seconds (CAN-SPAM requirement)
-
----
-
-## Who to Pair With
-- `backend-developer` — for queue implementation and webhook handling
-- `security-engineer` — for email token security (reset links, magic links)
-- `devops-engineer` — for DNS configuration and monitoring
-
----
-
-## Tools
-**ESP:** Resend · SendGrid · Postmark · AWS SES  
-**Testing:** mail-tester.com · Litmus · Email on Acid  
-**DNS check:** MXToolbox · DMARC Analyzer  
-**Templates:** React Email · MJML  
-**Queue:** BullMQ / Inngest / Trigger.dev

package/template/agent/skills/game-design/SKILL.md

@@ -1,194 +0,0 @@
----
-name: game-design
-description: Use when designing game mechanics, core loops, progression systems, monetization for games, difficulty curves, tutorial design, or player psychology
----
-
-# Game Design Lens
-
-> **Philosophy:** Game design is the art of making decisions fun. Every system should answer: "Is this engaging?"
-> The best games feel instantly playable and endlessly deep.
-
----
-
-## Core Instincts
-
-- **Core loop first** — if the core action isn't fun by itself, no meta-game will save it
-- **Feel before balance** — a perfectly balanced but bad-feeling game fails; great feel forgives imbalance
-- **Teach through play** — tutorials are a design failure if players need to read them
-- **Intrinsic over extrinsic motivation** — players who play for rewards quit when rewards stop
-- **Every system must serve the fantasy** — if a mechanic doesn't reinforce the core fantasy, cut it
-
----
-
-## Game Loop Hierarchy
-
-```
-Core Loop (seconds):   The primary action (shoot, match, tap, build)
-Meta Loop (minutes):   Progression within a session (upgrade, complete level)
-Outer Loop (days):     Long-term progression (unlock, prestige, story)
-
-Addiction comes from nested loops where each satisfies before feeding into the next.
-
-Example: Clash Royale
-  Core:  Battle (3 min)
-  Meta:  Earn chest, open chest, get cards
-  Outer: Climb trophies, unlock arenas, seasonal ladder
-```
-
----
-
-## Player Motivation (Bartle Types)
-
-| Type | Motivation | Engage with |
-|------|-----------|-------------|
-| **Achiever** | Goals, completion, rewards | Achievements, leaderboards, progress bars |
-| **Explorer** | Discovery, secrets, lore | Hidden content, procedural worlds, narrative |
-| **Socializer** | Connection, competition, cooperation | Guilds, co-op, chat, gifting |
-| **Killer** | Competition, dominance | PvP, rankings, bragging rights |
-
-**Indie hacker tip:** Mobile casual games are mostly Achievers. Design clear goals and visible progress.
-
----
-
-## Difficulty Curve Design
-
-```
-Flow State (Csikszentmihalyi):
-  Too hard → frustration → quit
-  Too easy → boredom → quit
-  Balanced → flow → engagement
-
-Difficulty progression rule:
-  Introduce mechanic (easy) → test mechanic (medium) → combine mechanics (hard)
-  Never introduce two new mechanics simultaneously
-
-Rubber-band difficulty:
-  Dynamic difficulty adjustment (DDA): losing players get slight boost
-  Winning players face slight increase
-  Keeps sessions competitive without feeling rigged
-```
-
----
-
-## Monetization Design for Games
-
-| Model | Player experience | Retention impact | Revenue potential |
-|-------|------------------|-----------------|------------------|
-| **Premium** (one-time) | ✅ No friction | ✅ High | 🔴 Capped |
-| **IAP — cosmetics only** | ✅ No frustration | ✅ Good | 🟡 Medium |
-| **IAP — progression** | ⚠️ Pay-to-win risk | ⚠️ Can harm f2p | 🟡 Medium |
-| **Rewarded ads** | ✅ Player-initiated | ✅ Good if not forced | 🟡 Medium |
-| **Battle pass** | ✅ FOMO + value | ✅ High (retention driver) | 🟢 High |
-| **Subscriptions** | ✅ Predictable | ✅ Good | 🟢 High |
-| **Gacha / loot boxes** | ⚠️ Controversy | ⚠️ Can be predatory | 🟢 High |
-
-**Indie hacker safe defaults:** Rewarded ads + battle pass + cosmetic IAP.
-**Avoid:** Pay-to-win IAP — destroys community trust and long-term retention.
-
----
-
-## Onboarding / Tutorial Design Rules
-
-```
-Rule 1: Show, don't tell — demonstrate mechanics, don't explain them
-Rule 2: Force the action — don't ask "do you want a tutorial?"; just do it
-Rule 3: Reward immediately — first tutorial action must give satisfying feedback
-Rule 4: FTUE (First-Time User Experience) must complete in < 3 minutes
-Rule 5: Every tutorial step has exactly ONE objective
-Rule 6: Remove all failure states during tutorial — frustration at minute 1 = uninstall
-Rule 7: No text walls — max 2 lines of instruction; ideally zero
-```
-
----
-
-## Game Balance Framework
-
-```
-Dominant strategy = game is solved → players get bored
-No viable strategy = game is frustrating → players quit
-
-Balanced game: multiple viable strategies, each with clear strengths and weaknesses
-
-Rock-Paper-Scissors model:
-  A beats B, B beats C, C beats A
-  No single dominant option; strategy matters
-
-Formulas:
-  DPS = Damage / Attack Speed
-  TTK (Time to Kill) = Target HP / DPS
-  Win rate = (Wins) / (Wins + Losses) — target ~50% ± 5% for PvP balance
-```
-
----
-
-## Game Metrics (KPIs)
-
-| Metric | Definition | Target |
-|--------|-----------|--------|
-| D1 Retention | % players returning on day 1 | > 35% |
-| D7 Retention | % players returning on day 7 | > 15% |
-| D28 Retention | % players returning on day 28 | > 7% |
-| Session length | Average time per session | 5–15 min (casual), 20–60 min (core) |
-| Sessions per DAU | Average sessions per daily user | > 2 |
-| ARPDAU | Revenue per daily active user | Varies; $0.05–$0.20 mobile casual |
-| IPM (Installs per Mille) | Ad creative installs / 1K impressions | > 3 for performance |
-| Day 0 tutorial completion | % who finish tutorial | > 70% |
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Skip the core loop to build meta first | Meta can't save a bad core loop | Fun core loop in < 2 weeks prototype |
-| Pay-to-win IAP | Destroys PvP balance, harms f2p players | Cosmetics, convenience (not power) |
-| Energy/timer gates early in FTUE | Players quit before experiencing value | First gate after player is hooked (> D3) |
-| Tutorial that can be failed | Guaranteed failure = guaranteed uninstall | Guided, railroaded tutorial with no lose state |
-| Random difficulty spikes | Perceived unfairness = rage quit | Smooth curve with intentional "boss" moments |
-| Introducing 2 mechanics at once | Cognitive overload | One mechanic per level/screen |
-| Rewarded ads forced (not voluntary) | Players hate interruption | Rewarded only — player initiates |
-
----
-
-## Questions You Always Ask
-
-**When designing a new mechanic:**
-- Is this fun by itself? (Test with just the mechanic, no rewards)
-- Does it reinforce the core fantasy of the game?
-- How does a new player encounter this for the first time?
-
-**When reviewing a level/system:**
-- Does the difficulty curve make sense? No sudden spikes?
-- What's the win rate data? (If PvP or competitive)
-- What's the tutorial completion rate for this flow?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] Tutorial can be failed or skipped with no guidance
-- [ ] First session longer than 5 minutes before first reward
-- [ ] Pay-to-win mechanics that affect PvP balance
-- [ ] No distinct core loop (what does the player DO every 30 seconds?)
-
-**Should fix:**
-- [ ] No audio/haptic feedback on primary action
-- [ ] Difficulty spikes without escalation curve
-- [ ] Monetization gating content needed to progress (not convenience)
-
----
-
-## Who to Pair With
-- `game-developer` — for technical implementation of mechanics
-- `mobile-developer` — for mobile UX and platform guidelines
-- `monetization-strategist` — for IAP pricing and revenue modeling
-- `retention-specialist` — for D1/D7/D28 funnel analysis
-
----
-
-## Reference Frameworks
-- **MDA Framework** (Mechanics → Dynamics → Aesthetics) — Hunicke, LeBlanc, Zubek
-- **Bartle's Player Types** — motivation segmentation for multiplayer
-- **Flow State** — Csikszentmihalyi's challenge/skill balance
-- **Octalysis** — Yu-kai Chou's gamification framework (8 core drives)