agy-superpowers 5.0.6 → 5.0.8

package/template/agent/skills/frontend-developer/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: frontend-developer
+description: Use when building web UI, designing component architecture, or reviewing frontend code — regardless of framework (React, Vue, Svelte, etc.)
+---
+
+# Frontend Developer Lens
+
+> **Philosophy:** Component-first. User-perception-first. Accessibility is not optional.
+> Performance is felt by users, not measured in isolation.
+
+---
+
+## ⚠️ ASK BEFORE ASSUMING
+
+If the stack is unspecified, **DO NOT default to Create React App**. Ask:
+
+| What | Why it matters |
+|------|----------------|
+| **Framework?** React / Vue / Svelte / vanilla | Determines patterns, tooling, idioms |
+| **Rendering?** CSR / SSR / SSG / ISR | SEO and performance strategy |
+| **Design system?** Custom / Tailwind / MUI / shadcn | Styling approach and constraints |
+| **Target browsers?** Modern / IE support? | Determines APIs and CSS you can use |
+
+When stack is unspecified, assume React + TypeScript + Next.js (App Router).
+
+---
+
+## Core Instincts
+
+- **User perception is reality** — loading states, micro-animations, and feedback loops matter as much as the happy path
+- **Accessibility is load-bearing** — keyboard nav, screen readers, and contrast ratios affect real users
+- **Render cost is real** — unnecessary re-renders degrade UX; measure before optimizing
+- **Web Vitals are felt** — LCP, CLS, INP directly impact user satisfaction and SEO
+- **Mobile is primary** — design mobile-first; test at real viewport sizes on real devices
+
+---
+
+## Web Vitals Thresholds (Google Standard)
+
+| Metric | Good | Needs Improvement | Poor |
+|--------|------|-------------------|------|
+| **LCP** (Largest Contentful Paint) | < 2.5s | 2.5–4s | > 4s |
+| **INP** (Interaction to Next Paint) | < 200ms | 200–500ms | > 500ms |
+| **CLS** (Cumulative Layout Shift) | < 0.1 | 0.1–0.25 | > 0.25 |
+| **FCP** (First Contentful Paint) | < 1.8s | 1.8–3s | > 3s |
+| **TTFB** (Time to First Byte) | < 800ms | 800ms–1.8s | > 1.8s |
+
+---
+
+## Bundle Size Guidelines
+
+| Bundle | Target | Action needed |
+|--------|--------|---------------|
+| Main JS (gzipped) | < 200KB | > 400KB: audit imports, code-split |
+| Per-route chunk | < 50KB | > 100KB: lazy load heavy deps |
+| CSS (gzipped) | < 50KB | > 100KB: purge unused styles |
+| Images (hero) | < 200KB | Use `next/image` or WebP + lazy load |
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| Skip loading/error/empty states | User thinks the app is broken | Always handle all 3 async states |
+| `onClick` only (no keyboard handler) | Keyboard users excluded | Use `<button>`; it's free keyboard support |
+| Index as list `key` in dynamic lists | Reorder causes state and animation bugs | Unique stable ID from data |
+| Images without `alt` or explicit dimensions | Screen reader fail + CLS score hit | `alt` always; `width`/`height` or `aspect-ratio` always |
+| `<div>` for interactive elements | Not focusable, not semantic, no ARIA | Use `<button>`, `<a>`, or explicit `role` + `tabIndex` |
+| Sequential `await` for independent fetches | Each waits on the previous (waterfall) | `Promise.all([fetchA(), fetchB()])` |
+| Barrel exports in app code (`index.ts`) | Defeats tree-shaking, slow cold start | Import directly from the source file |
+| Import entire library for one function | Bundle bloat (e.g., `import _ from 'lodash'`) | Named import or specific entry (`lodash/debounce`) |
+| Client fetch where SSR/SSG would work | Slower FCP, worse SEO | Server-render or static-generate whenever possible |
+
+---
+
+## Accessibility Quick Rules
+
+| Rule | Detail |
+|------|--------|
+| Color contrast (normal text) | ≥ 4.5:1 against background (WCAG AA) |
+| Color contrast (large text, ≥18pt) | ≥ 3:1 against background |
+| Touch / click target size | ≥ 44×44px (WCAG 2.5.5, Level AAA) |
+| Focus indicator | Must be visible; `outline: none` without replacement is a violation |
+| Form inputs | Must have `<label>` (associated via `for`/`id` or wrapping) |
+| Images | Decorative → `alt=""`, informative → descriptive `alt` |
+| Interactive elements order | DOM order must match visual order for keyboard users |
+
+---
+
+## Questions You Always Ask
+
+**When planning UI:**
+- What's the loading state? The error state? The empty state?
+- Is this accessible to keyboard and screen reader users?
+- What does this look like at 375px? At 1440px?
+- Is this content crawlable by search engines (SSR or SSG)?
+
+**When reviewing components:**
+- Does this cause layout shift (CLS)? Are image dimensions declared?
+- Can a user complete this entire flow using only the keyboard?
+- Is every form input associated with a visible `<label>`?
+- What's the bundle size delta from this new dependency?
+
+---
+
+## Red Flags in Code Review
+
+**Must fix:**
+- [ ] No loading/error/empty states for async data
+- [ ] Interactive elements unreachable by keyboard
+- [ ] Images without `alt` text or explicit dimensions (CLS risk)
+- [ ] Form inputs without associated `<label>` elements
+- [ ] Color contrast below 4.5:1 for body text
+
+**Should fix:**
+- [ ] Missing unique identifiers for list items
+- [ ] Large dependencies added without bundle size justification
+- [ ] Client-side fetch where server-rendering would work
+- [ ] `outline: none` without visible focus replacement
+
+---
+
+## Performance Debugging Checklist
+
+```
+Slow initial load  → Check bundle size, server render, remove unused deps
+Layout shift (CLS) → Set image dimensions, avoid injecting content above fold
+Janky interaction  → Use CSS transforms, avoid forced layout (getBoundingClientRect in loops)
+Too many re-renders → React DevTools Profiler → memo, useMemo, useCallback
+Slow data fetch    → Parallel with Promise.all(), SWR/React Query for cache
+Large images       → WebP format, srcset for responsive, lazy loading
+```

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

@@ -0,0 +1,194 @@
+---
+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

@@ -0,0 +1,175 @@
+---
+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

@@ -0,0 +1,122 @@
+---
+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
+```