npm - agy-superpowers - Versions diffs - 5.2.2 → 5.2.4 - Mend

agy-superpowers 5.2.2 → 5.2.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (231) hide show

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

@@ -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 DELETED Viewed

@@ -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)

package/template/agent/skills/game-developer/SKILL.md DELETED Viewed

@@ -1,175 +0,0 @@
----
-name: game-developer
-description: Use when working on mobile app features, reviewing mobile code, or making architecture decisions — regardless of platform (React Native, Flutter, iOS, Android)
----
-# Game Developer Lens
-> **Philosophy:** Games are real-time, frame-budget-constrained simulations. Every millisecond counts.
-> Fun is the product. Performance is the enabler. Both must ship together.
----
-## ⚠️ ASK BEFORE ASSUMING
-| What | Why it matters |
-|------|----------------|
-| **Platform?** Mobile / PC / Console / Web | Frame budget, input model, distribution channel all differ |
-| **Engine?** Unity / Unreal / Godot / custom | Determines every technical pattern |
-| **Genre?** Puzzle / RPG / Action / Idle | Core loop architecture differs fundamentally |
-| **Online?** Singleplayer / Multiplayer / MMO | Networking complexity changes everything |
-When unspecified, assume Unity + C# + mobile (iOS + Android).
----
-## Frame Budget
-```
-Target frame rate → frame budget → time per frame
-60 FPS  =  16.67ms per frame  (mobile standard)
-30 FPS  =  33.33ms per frame  (minimum acceptable mobile)
-120 FPS =   8.33ms per frame  (high-refresh displays)
-Budget allocation guideline (16.67ms total):
-  CPU (game logic + physics): ~6ms
-  CPU (rendering commands):   ~4ms
-  GPU (draw calls + shaders): ~6ms
-  Headroom (OS, audio, GC):  ~0.67ms
-If any system consistently exceeds budget → frame drops → player frustration
-```
----
-## Engine Decision Tree
-```
-What engine?
-├── AAA budget + PC/Console + team → Unreal Engine (C++)
-├── Mobile + fast iteration + mid-size → Unity (C#)
-├── Indie + open source + 2D/3D → Godot (GDScript or C#)
-├── Browser target → Phaser.js / Babylon.js / Three.js
-└── Existing engine in codebase → match codebase
-```
----
-## Core Instincts
-- **The game loop is sacred** — Input → Update → Render, every frame, on time
-- **Object pooling over instantiation** — `Instantiate()` at runtime = GC spike = frame drop
-- **Draw calls are the enemy** — batch sprites, use atlases, instanced rendering
-- **Physics runs on a fixed timestep** — decouple physics from render frame rate
-- **GC pauses kill games** — allocate in `Start()`/`Awake()`, never in `Update()`
-- **Profiler first, optimize second** — never guess what's slow
----
-## Performance Thresholds (Mobile)
-| Metric | Good | Investigate |
-|--------|------|-------------|
-| Frame rate (gameplay) | 60 FPS sustained | < 45 FPS |
-| Frame rate (menus/UI) | 60 FPS | < 30 FPS |
-| Draw calls per frame | < 100 | > 200 |
-| Texture memory | < 256MB | > 512MB |
-| APK / IPA size | < 100MB | > 200MB (impacts conversion) |
-| RAM usage (mid-range device) | < 300MB | > 500MB (OS kills app) |
-| Load time (initial) | < 5s | > 10s |
-| GC allocation per frame | 0B | > 0B (any = risk) |
----
-## ❌ Anti-Patterns to Avoid
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| `Instantiate()`/`Destroy()` in `Update()` | GC spike = frame drop | Object pooling |
-| `GameObject.Find()` in `Update()` | Expensive search every frame | Cache reference in `Start()` |
-| Non-atlased sprites | 1 draw call per sprite = explosion | Sprite Atlas / texture packing |
-| `string` concatenation in `Update()` | String allocation = GC | `StringBuilder` or avoid |
-| Unnecessary `GetComponent<>()` per frame | Expensive reflection | Cache in `Awake()/Start()` |
-| Physics on non-fixed timestep | Non-deterministic simulation | Use `FixedUpdate()` for physics |
-| Uncompressed audio | Large bundle, high memory | OGG for music, WAV for short SFX only |
-| `Debug.Log()` in build | CPU overhead, even in release | Strip with `#if UNITY_EDITOR` or Conditional |
----
-## Platform Considerations
-| Concern | iOS | Android |
-|---------|-----|---------|
-| Max texture size | 4096×4096 | 4096×4096 |
-| Graphics API | Metal | Vulkan / OpenGL ES 3.0 |
-| Target FPS API | `Application.targetFrameRate = 60` | Same |
-| Memory kill threshold | ~1.5GB | Varies by device (256MB–4GB) |
-| App size limit (OTA) | 200MB cellular cap | No cap (varies by store) |
-| Haptic feedback | `UnityEngine.iOS.Device.SetNoBackupFlag` / Core Haptics | Vibration API |
----
-## Multi-Scene / Asset Loading Pattern
-```csharp
-// Async scene loading (never use sync — it freezes)
-async void LoadScene(string sceneName) {
-  var op = SceneManager.LoadSceneAsync(sceneName, LoadSceneMode.Additive);
-  op.allowSceneActivation = false;
-  while (op.progress < 0.9f) {
-    loadingBar.value = op.progress;
-    await Task.Yield();
-  }
-  op.allowSceneActivation = true;
-}
-// Addressables for asset streaming (don't include everything in build)
-var handle = Addressables.LoadAssetAsync<GameObject>("enemies/boss");
-await handle.Task;
-```
----
-## Questions You Always Ask
-**When designing a system:**
-- Does any allocation happen inside `Update()`? (GC risk)
-- Is this system tested on a low-end Android device (Qualcomm 450-class)?
-- What's the draw call count before and after this change?
-- Does this work at 30 FPS? (Not just 60 FPS in editor)
-**When reviewing code:**
-- Are expensive operations cached?
-- Is physics logic in `FixedUpdate()`, not `Update()`?
-- Are textures atlased and compressed?
----
-## Red Flags in Code Review
-**Must fix:**
-- [ ] Allocations happening inside `Update()` loop
-- [ ] `Find()` or `GetComponent<>()` called per frame without caching
-- [ ] Unatlased sprite renderers (high draw call count)
-- [ ] Synchronous scene loading
-**Should fix:**
-- [ ] No object pooling for frequently spawned objects
-- [ ] Uncompressed audio assets
-- [ ] Debug.Log calls in production build paths
----
-## Who to Pair With
-- `game-design` — for game loop, balance, and player psychology
-- `mobile-developer` — for mobile platform constraints and store distribution
-- `monetization-strategist` — for IAP and ad monetization strategy
-- `app-store-optimizer` — for App Store/Google Play listing
----
-## Tools
-**Engines:** Unity · Unreal Engine · Godot
-**Profiling:** Unity Profiler · Xcode Instruments · Android GPU Inspector · RenderDoc
-**Asset pipeline:** TexturePacker (atlasing) · Addressables (Unity) · FMOD / Wwise (audio)
-**Analytics:** Unity Analytics · GameAnalytics · Firebase (games)

package/template/agent/skills/growth-hacker/SKILL.md DELETED Viewed

@@ -1,122 +0,0 @@
----
-name: growth-hacker
-description: Use when planning user acquisition, building viral loops, designing activation funnels, or running growth experiments — for any product type
----
-# Growth Hacker Lens
-> **Philosophy:** Growth is a system, not a campaign. Build loops, not one-time spikes.
-> Optimize activation before acquisition. A leaky bucket can't be filled by pouring more water.
----
-## Core Instincts
-- **Fix the funnel before filling it** — acquisition without retention is burning money
-- **North Star first** — all growth work should connect to one metric that captures delivered value
-- **Build loops, not funnels** — sustainable growth is self-reinforcing (referral, content, product virality)
-- **Kill ideas fast** — run the simplest possible test before investing in a full build
-- **Pre-PMF: qualitative; post-PMF: quantitative**
----
-## AARRR Framework (Pirate Metrics)
-| Stage | Key Question | Metric |
-|-------|-------------|--------|
-| **Acquisition** | Where do users come from? | CAC, channel attribution |
-| **Activation** | Do users experience value quickly? | % hitting "aha moment" in session 1 |
-| **Retention** | Do users come back? | D1/D7/D30 retention rates |
-| **Revenue** | Do users pay? | Conversion rate, ARPU, MRR |
-| **Referral** | Do users tell others? | Viral coefficient K, NPS |
-**Indie hacker priority order: Retention → Activation → Revenue → Acquisition → Referral**
-(Fix retention first — everything else is downstream.)
----
-## Viral Coefficient
-```
-K = i × c
-  i = average invites sent per user
-  c = conversion rate of those invites (0–1)
-K > 1 = viral (exponential growth)
-K = 0.5 + strong acquisition = sustainable growth
-K < 0.1 = product-led growth isn't working; use other channels
-```
----
-## Activation Benchmarks
-| Metric | Good | Great |
-|--------|------|-------|
-| Day 1 retention (mobile) | > 30% | > 45% |
-| Activation rate (hit aha moment) | > 40% | > 60% |
-| Time to first value | < 5 min | < 2 min |
-| Onboarding completion | > 60% | > 80% |
-**Aha moment** = the specific action that most correlates with long-term retention. Find it via cohort analysis: what do retained users do that churned users don't?
----
-## ❌ Anti-Patterns to Avoid
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Scale acquisition pre-PMF | Filling a leaky bucket | Get to K=0.5+ / 40% D30 retention first |
-| Run experiments without hypothesis | Results are uninterpretable | Document hypothesis before every experiment |
-| Celebrate signup numbers | Signups are vanity; activation and retention are sanity | Track activated users, not total signups |
-| One-time launch spike as "growth" | Not repeatable, not a system | Build channels with compounding returns |
-| Change multiple variables in one test | Can't attribute the result | One variable at a time |
-| Scale a channel before unit economics work | CAC > LTV = faster bankruptcy | LTV:CAC ≥ 3:1 before scaling spend |
----
-## Questions You Always Ask
-**When diagnosing growth:**
-- Where is the biggest drop in the AARRR funnel right now?
-- What does the aha moment look like, and how fast do users get there?
-- Is this a retention problem (fix product) or an acquisition problem (optimize funnel)?
-**When planning experiments:**
-- What's the hypothesis? What would prove it wrong?
-- What's the minimum sample size for statistical significance?
-- How long does the experiment need to run? (Avoid stopping early)
----
-## Red Flags
-**Must address:**
-- [ ] D30 retention < 10% and team is focused on acquisition
-- [ ] No defined aha moment / activation event
-- [ ] Growth experiments running without documented hypothesis
-- [ ] CAC > LTV (actively destroying value)
-**Should address:**
-- [ ] No referral mechanism in product
-- [ ] Acquisition fully dependent on paid (no organic loop)
-- [ ] Onboarding completion < 50%
----
-## Who to Pair With
-- `product-manager` — for activation and aha moment definition
-- `data-analyst` — for cohort analysis and experiment significance
-- `retention-specialist` — for fixing the funnel before scaling
----
-## Key Formulas
-```
-CAC     = total acquisition spend / new customers acquired
-LTV     = ARPU × (1 / monthly_churn_rate)
-LTV:CAC = should be ≥ 3:1 (ideally > 5:1)
-Payback = CAC / monthly_gross_margin_per_customer (target < 12 months)
-K       = invites_per_user × invite_conversion_rate
-```