agy-superpowers 5.2.2 → 5.2.3

package/template/agent/skills/chrome-extension-developer/SKILL.md

@@ -1,53 +0,0 @@
----
-name: chrome-extension-developer
-description: Use when building a Chrome extension, browser extension, or browser-based tool
----
-
-# Chrome Extension Developer Lens
-
-## Identity
-Think in isolated contexts and specific browser APIs. You are building software that lives inside another piece of software. Security, permissions, and extension architecture are your primary constraints.
-
-## Core Instincts
-- **Manifest V3 is the only way** — background pages are dead; service workers rule. All new extensions must use MV3.
-- **Least privilege principle** — every permission requested must be justified to the Chrome Web Store reviewers. Over-requesting leads to rejection.
-- **Context isolation** — understand the boundaries between the popup, the content script, and the service worker. They cannot share variables directly.
-- **Message passing is the nervous system** — since contexts are isolated, data moves via `chrome.runtime.sendMessage` and `chrome.tabs.sendMessage`.
-
-## Core Knowledge
-
-**Manifest V3 Architecture:**
-- **Service Workers:** Ephemeral background tasks (wakes up on events, goes to sleep). No DOM access.
-- **Content Scripts:** Runs in the context of webpages. Can read/modify the DOM, but cannot use most `chrome.*` APIs.
-- **Popup/Options Page:** Standard HTML/JS environments. Can use all permitted `chrome.*` APIs.
-- **Side Panel API:** For persistent UI across different tabs.
-
-**Permission Strategy:**
-- Prefer `activeTab` over broad host permissions (`<all_urls>` or `*://*/*`). `activeTab` grants temporary access when the user clicks the extension icon, satisfying most use cases without triggering intense security reviews.
-
-**Storage Patterns:**
-- `chrome.storage.local`: For device-specific data and larger objects (up to 10MB by default, 5MB if unthrottled).
-- `chrome.storage.sync`: For user preferences across devices (max 100KB, max 8KB per item). Do NOT store sensitive data here (it syncs to Google servers).
-
-**Common Extension Patterns:**
-- Content injection (floating buttons on specific sites)
-- Sidebar overlay (using Shadow DOM to avoid CSS conflicts with the host page)
-- New tab override
-- Context menu items
-
-## Distribution & Monetization
-- Chrome Web Store listing optimization is your main growth channel.
-- **Monetization:** Freemium is most common. Premium features gated behind Stripe ($3-$10/mo or $29-$99 lifetime).
-
-## Questions You Always Ask
-- Can we achieve this with `activeTab` instead of requesting host permissions?
-- Is this state being stored in the service worker? (It shouldn't be, service workers die).
-- How are we passing this message between the content script and the background?
-- Are we evaluating arbitrary strings? (No `eval()` allowed by CSP rules).
-
-## Red Flags / Anti-Patterns
-- [ ] Requesting `<all_urls>` permission when `activeTab` suffices (will delay or reject review)
-- [ ] Using background pages instead of service workers (MV3 incompatible)
-- [ ] Storing sensitive user data or large objects in `chrome.storage.sync`
-- [ ] No error handling for `chrome.runtime.lastError` after API calls
-- [ ] Relying on global variables in a service worker to persist state

package/template/agent/skills/community-manager/SKILL.md

@@ -1,115 +0,0 @@
----
-name: community-manager
-description: Use when building and managing communities on Discord, Reddit, Slack, or social platforms — including moderation, engagement strategy, and community-led growth
----
-
-# Community Manager Lens
-
-> **Philosophy:** Communities are built on belonging, not broadcasting. The best communities make members feel seen, not sold to.
-> A thriving community is retention infrastructure — users who belong don't churn.
-
----
-
-## Core Instincts
-
-- **Give before you take** — provide value for months before asking for anything
-- **10× rule** — for every self-promotional post, create 10 pieces of pure value
-- **Lurkers are members too** — 90% of community members never post; they still get value and stay
-- **Rules enable culture** — clear community guidelines protect the vibe early; retrofit is painful
-- **First 100 members make or break the culture** — seed with high-quality people
-
----
-
-## Community Growth Stages
-
-| Stage | Size | Focus |
-|-------|------|-------|
-| **Seeding** | 0–50 | Hand-recruit ideal members; personal invitations only |
-| **Nurturing** | 50–500 | Daily engagement, create rituals, establish culture |
-| **Scaling** | 500–5K | Empower moderators, create sub-channels, systematize onboarding |
-| **Sustaining** | 5K+ | Ambassador programs, community-led content, governance |
-
----
-
-## Platform Comparison
-
-| Platform | Best for | Retention | Discovery |
-|----------|----------|-----------|-----------|
-| **Discord** | Real-time, developer tools, games | High | Low (invite-only) |
-| **Reddit** | SEO, async discussion, niche topics | Medium | High (searchable) |
-| **Slack** | B2B SaaS, professional communities | Medium | Low |
-| **Circle / Mighty Networks** | Paid communities, courses | High | Low |
-| **X (Twitter)** | Thought leadership, broad reach | Low | High |
-
----
-
-## Engagement Health Metrics
-
-| Metric | Below avg | Average | Healthy |
-|--------|-----------|---------|---------|
-| Monthly active members / total | < 5% | 10–20% | > 25% |
-| Post-to-member ratio (monthly) | < 0.5 | 1–3 | > 5 |
-| Average replies per thread | < 1 | 2–4 | > 5 |
-| Moderation actions / posts | > 20% | 5–10% | < 3% |
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Launch with 0 content | Ghost town = no one stays | Pre-seed with 10–20 threads before inviting |
-| Broadcast-only (announcements, no discussion) | Feels like a newsletter, not a community | Invite discussion; ask questions more than announce |
-| No moderation in first week | Bad actors set the culture early | Establish rules + remove violators immediately |
-| Ignore members' questions | Signals you don't care | Respond to every post in first 3 months |
-| Open community too early | Wrong early members = culture damage | Curated waitlist; invite manually first 50–100 |
-| Over-channel too early | Channel sprawl kills activity | Start with 3–5 channels; add only when needed |
-
----
-
-## Questions You Always Ask
-
-**When launching a community:**
-- Who are the ideal first 10 members? Can I personally invite them?
-- What's the community promise — why should someone join AND stay?
-- What weekly ritual will drive recurring engagement? (Show & Tell, Feedback Friday, etc.)
-- What are the 3 non-negotiable community rules?
-
-**When diagnosing a declining community:**
-- What's the monthly active rate? (< 10% = engagement problem)
-- When was the last "member-initiated" post (not admin-started)?
-- What do lapsed members say when you reach out directly?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] Community active rate < 5% (mostly lurkers with no engagement)
-- [ ] Only admins posting — no member-initiated discussions
-- [ ] No community guidelines posted or enforced
-- [ ] Questions from members going unanswered > 24 hours
-
-**Should fix:**
-- [ ] No onboarding flow for new members (first experience = blank discord)
-- [ ] No weekly recurring engagement ritual
-- [ ] > 20 channels with similar topics (channel sprawl)
-
----
-
-## Who to Pair With
-- `retention-specialist` — community is a retention channel
-- `content-marketer` — for content seeding and distribution within community
-- `growth-hacker` — for community-led referral and viral loops
-
----
-
-## Community Onboarding Template
-
-```
-New member joins →
-1. Auto-welcome message with 3 things to do first
-2. Introduce yourself thread (pinned)
-3. Highlight 3 best threads from last month
-4. Personal DM from founder/moderator within 48h
-```

package/template/agent/skills/content-marketer/SKILL.md

@@ -1,111 +0,0 @@
----
-name: content-marketer
-description: Use when planning content strategy, SEO content, social media, email newsletters, or building an audience-driven growth channel
----
-
-# Content Marketer Lens
-
-> **Philosophy:** Distribution > creation. A great post no one reads is a wasted asset.
-> Build an audience once; it compounds. Ad spend stops the moment you stop paying.
-
----
-
-## Core Instincts
-
-- **Audience-first** — write for a specific person with a specific problem, not "everyone"
-- **Distribution is 80% of the work** — repurpose and distribute before writing something new
-- **SEO content compounds; social content decays** — prioritize search-indexed content for long-term ROI
-- **Consistency beats brilliance** — publishing schedule > single viral posts
-- **Content-market fit** — content that your audience shares is content aligned with their identity
-
----
-
-## Content Funnel (TOFU / MOFU / BOFU)
-
-| Stage | Goal | Content Types |
-|-------|------|--------------|
-| **ToFU** (Top of Funnel) | Awareness | Blog posts, social threads, short videos, podcasts |
-| **MoFU** (Middle of Funnel) | Consideration | Case studies, comparison pages, email sequences, webinars |
-| **BoFU** (Bottom of Funnel) | Conversion | Landing pages, testimonials, free trial CTAs, pricing explainers |
-
-**Indie hacker allocation:** 60% ToFU (audience building), 30% MoFU (nurture), 10% BoFU (convert).
-
----
-
-## Distribution Channels (Ranked by Compounding ROI)
-
-| Channel | Compounding? | Time to results | Best for |
-|---------|-------------|----------------|----------|
-| SEO blog | ✅ High | 3–12 months | B2B SaaS, tools |
-| Email newsletter | ✅ Medium | 1–6 months | Direct relationship, loyalty |
-| YouTube | ✅ Medium | 6–18 months | Tutorial/educational products |
-| Twitter/X threads | ❌ Low | Days | Brand building, distribution boosts |
-| Reddit / Hacker News | ❌ Low | Hours | Launch spikes, community credibility |
-| TikTok / Reels | ❌ Low | Days | Consumer apps, B2C |
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Write content without SEO research | Invisible to search, no compounding | Keyword research first |
-| Post on all platforms simultaneously | Mediocre everywhere | Own 1–2 channels deeply |
-| Copy competitor content strategy | Different audience, different context | Find your unique POV |
-| Create content without repurposing plan | 1x effort, 1x reach | 1 blog → 5 tweets → 1 email → 1 short video |
-| No call to action | Content without conversion intent | Every piece has one next step |
-| Publish once, never promote | Content ROI is mostly in distribution | Promote each piece for 30 days post-publish |
-
----
-
-## Content Benchmarks
-
-| Metric | Good | Great |
-|--------|------|-------|
-| Email open rate | > 25% | > 40% |
-| Email CTR | > 3% | > 8% |
-| Blog organic traffic growth (MoM) | > 10% | > 25% |
-| Social follower-to-click rate | > 1% | > 3% |
-| Newsletter subscriber monthly growth | > 5% | > 15% |
-
----
-
-## Questions You Always Ask
-
-**When planning content:**
-- Who specifically is reading this? What's their pain, and what's their next question?
-- What's the keyword or search intent behind this piece? (Even for social content: what would someone search to find this?)
-- How will we distribute this after publishing?
-- What's the one action we want the reader to take?
-
-**When auditing a content strategy:**
-- What % of content is indexed by search (long-term asset) vs ephemeral?
-- Is there a consistent publishing schedule? (Consistency signals authority)
-- What's the email list growth rate? (Email = owned audience)
-
----
-
-## Red Flags
-
-**Must address:**
-- [ ] No keyword research behind blog content
-- [ ] No email list / owned audience being built
-- [ ] Team creates content but has no distribution plan
-- [ ] Publishing inconsistently (< 2 posts/month)
-
-**Should address:**
-- [ ] No repurposing workflow (each piece used only once)
-- [ ] No content calendar (reactive publishing)
-- [ ] No measurement of content-attributed signups
-
----
-
-## Who to Pair With
-- `seo-specialist` — for keyword strategy and technical SEO
-- `copywriter` — for copy quality and audience resonance
-- `data-analyst` — for content attribution and funnel tracking
-
----
-
-## Tools
-Beehiiv · Substack · ConvertKit (email) · Ahrefs · Semrush (keyword research) · Buffer · Typefully (social scheduling) · Notion / Airtable (content calendar)

package/template/agent/skills/conversion-optimizer/SKILL.md

@@ -1,142 +0,0 @@
----
-name: conversion-optimizer
-description: Use when optimizing landing pages, trial-to-paid funnels, paywall design, onboarding flows, or running CRO experiments
----
-
-# Conversion Optimizer Lens
-
-> **Philosophy:** Conversion is about removing friction and increasing trust simultaneously.
-> Every unnecessary step, field, or decision is a drop in conversion rate.
-
----
-
-## Core Instincts
-
-- **Remove friction before adding persuasion** — simplify the path before optimizing copy
-- **Trust before conversion** — social proof, testimonials, and guarantees reduce purchase anxiety
-- **One page, one goal** — landing pages with multiple CTAs convert less than focused ones
-- **Mobile conversion is different** — form fields on mobile cost 20–30% more friction than desktop
-- **Test, don't guess** — opinions on what will convert are unreliable; data is not
-
----
-
-## Landing Page Above-the-Fold Formula
-
-```
-┌─────────────────────────────────────┐
-│  NAV: Logo | Pricing | Log in       │
-├─────────────────────────────────────┤
-│  HEADLINE: Clear benefit in <8 words│
-│  SUBHEADLINE: Who it's for + how    │
-│  CTA: [Single action button]        │
-│  SOCIAL PROOF: X users / logos /    │
-│               star rating           │
-├─────────────────────────────────────┤
-│  HERO IMAGE / VIDEO / SCREENSHOT    │
-└─────────────────────────────────────┘
-```
-
-**Required above-the-fold:** Headline + CTA + 1 trust signal. Everything else is below.
-
----
-
-## Conversion Benchmarks
-
-| Funnel Stage | Poor | Average | Good | Great |
-|-------------|------|---------|------|-------|
-| Visitor → Sign up | < 1% | 2–4% | 5–8% | > 10% |
-| Sign up → Activated | < 20% | 30–50% | 50–70% | > 75% |
-| Trial → Paid | < 5% | 8–15% | 15–25% | > 30% |
-| Paid → Annual (upsell) | < 20% | 25–35% | 35–50% | > 55% |
-| App Store impression → Install | < 2% | 3–5% | 6–8% | > 10% |
-
----
-
-## A/B Testing Rules
-
-| Rule | Detail |
-|------|--------|
-| **One variable per test** | Headline OR CTA OR layout — never multiple |
-| **Minimum sample size** | ≥ 1,000 visitors per variant before reading results |
-| **Statistical significance** | ≥ 95% confidence (p < 0.05) before declaring winner |
-| **Test duration** | Minimum 2 weeks (captures weekly seasonality) |
-| **Business significance** | > 5% lift is actionable; < 2% is noise regardless of p-value |
-
----
-
-## Paywall Design Principles
-
-- **Show upgrade prompt after activation event** — not before, not on open
-- **Anchor with annual** — show annual price first, monthly as secondary
-- **Offer 3 options max** — choice paralysis above 3 tiers
-- **Include a free trial CTA** — "Try free for 14 days" converts higher than "Subscribe now"
-- **Social proof on paywall** — "Join 12,000 users" or star rating
-- **Money-back guarantee** — even 7-day guarantee increases conversion 10–20%
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Multiple CTAs on one page | Users don't know what to do | One primary CTA per page/section |
-| Long sign-up form (> 3 fields) | Each field costs ~10% conversion | Minimum viable info: email only or SSO |
-| No social proof | Users don't trust new products | Number of users, testimonials, press logos |
-| Generic CTA ("Get Started") | No benefit communicated | Benefit-first CTA ("Start saving 2h/week") |
-| Testing without hypothesis | Unfalsifiable, results misinterpreted | Write hypothesis before running test |
-| Reading results too early | False positives from underpowered tests | Wait for 1000+ per variant + 2 weeks |
-| Paywall on first open (mobile) | Users haven't experienced value | Trigger after Nth use or activation event |
-
----
-
-## Onboarding Flow Optimization
-
-| Principle | Detail |
-|-----------|--------|
-| **Aha moment ASAP** | Every onboarding step that doesn't lead toward aha moment is a churn risk |
-| **Progressive disclosure** | Show only what's needed for the current step |
-| **No walls** | Avoid mandatory email verification before first experience |
-| **Personalization prompt** | 1 question to customize experience dramatically improves activation |
-| **Empty state = opportunity** | Show what the product looks like full, not an empty blank slate |
-
----
-
-## Questions You Always Ask
-
-**When auditing a landing page:**
-- Does the headline communicate the primary benefit in < 8 words?
-- Is there exactly one primary CTA?
-- Is there social proof visible above the fold?
-- What's the current visitor → signup conversion rate? (Benchmark: 3–8%)
-
-**When auditing a funnel:**
-- Where is the biggest drop-off in the funnel?
-- Has this been A/B tested, or is it based on opinion?
-- Is the paywall appearing before or after the activation event?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] Conversion rate tracking not set up (can't optimize what you can't measure)
-- [ ] Landing page has more than 2 CTAs
-- [ ] No social proof on landing page or paywall
-- [ ] Paywall shown before activation event
-
-**Should fix:**
-- [ ] Sign-up form has > 3 fields
-- [ ] No A/B testing tooling in place
-- [ ] No exit-intent capture on pricing page
-
----
-
-## Who to Pair With
-- `copywriter` — for headline and CTA copy
-- `monetization-strategist` — for paywall and pricing strategy
-- `data-analyst` — for funnel analysis and test significance
-
----
-
-## Tools
-Statsig · Optimizely · VWO (A/B testing) · Hotjar · Microsoft Clarity (session recording) · PostHog · Google Optimize (deprecated — use Statsig/VWO instead)

package/template/agent/skills/cto-architect/SKILL.md

@@ -1,133 +0,0 @@
----
-name: cto-architect
-description: Use when making system design decisions, managing technical debt, planning for scale, hiring engineers, or reviewing overall architecture
----
-
-# CTO / Architect Lens
-
-> **Philosophy:** Architecture is the decisions that are hard to reverse. Make them deliberately.
-> The best architecture is the simplest one that handles today's scale and doesn't prevent tomorrow's.
-
----
-
-## Core Instincts
-
-- **YAGNI at architecture scale** — don't build for 10M users when you have 10K
-- **Reversibility > correctness** — prefer decisions you can change over theoretically perfect ones
-- **Observability is not optional** — if you can't see your system failing, you can't fix it
-- **Write ADRs** — architectural decisions without documentation will be re-debated and reversed
-- **Boring technology wins** — proven, well-understood tools > novel shiny tools in production
-
----
-
-## Scale Progression (Don't Over-Engineer Early)
-
-| User scale | Recommended architecture |
-|-----------|--------------------------|
-| 0 – 10K MAU | Monolith + managed DB + single server (Railway/Fly/Render) |
-| 10K – 100K MAU | Monolith + read replica + CDN + caching layer (Redis) |
-| 100K – 1M MAU | Modular monolith, background job queues, horizontal scaling |
-| 1M+ MAU | Consider service extraction, streaming (Kafka), dedicated infra team |
-
-**Indie hacker signal:** If you don't have 100K MAU yet, you almost certainly don't need microservices.
-
----
-
-## Tech Debt Management
-
-| Category | Action |
-|---------|--------|
-| **Critical** (breaks things now or soon) | Fix in current sprint |
-| **Important** (slowing team down) | Schedule within next 2 sprints |
-| **Nice to fix** (code smell, not blocking) | Add to backlog; don't block on it |
-
-**Healthy tech debt budget:** ≤ 20% of sprint capacity. > 30% = team velocity will degrade.
-
-**ADR (Architecture Decision Record):** Every significant architectural choice should have: Context → Decision → Consequences. Store in `/docs/architecture/`.
-
----
-
-## System Design Principles
-
-**For APIs:**
-- Design for idempotence — same request = same result (safe to retry)
-- Version from day 1: `/v1/` prefix
-- Paginate everything that returns lists
-
-**For databases:**
-- Single writer, multiple readers (read replicas) before sharding
-- Index on columns you query/sort/filter by
-- Schema migrations: always backward-compatible + rollback script
-
-**For reliability:**
-- Circuit breakers around external API calls
-- Bulkhead pattern — isolate failures so one component can't take down others
-- Graceful degradation > hard failure
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Microservices at day 1 | Distributed systems complexity with no scale benefit | Monolith until pain forces it |
-| No caching strategy | DB bottleneck at moderate scale | Cache at CDN, application, and DB levels |
-| Shared mutable state between services | Impossible to reason about, cascading failures | Each service owns its data |
-| Schema migration as afterthought | One deploy breaks prod for hours | Migration in deploy pipeline, tested in staging |
-| Hire senior engineers only | Expensive, over-engineered, slow iteration | 1 senior for every 3–4 junior/mid |
-| Rewrite instead of refactor | "We'll rewrite it right this time" → new mess | Strangler fig pattern for legacy rewrites |
-| Single point of failure | One crash = all users down | Load balancer + multiple instances from early |
-
----
-
-## Hiring Benchmarks
-
-| Ratio | Rule |
-|-------|------|
-| Senior : Mid/Junior | 1 : 3–4 (sustainable) |
-| Engineer : product (B2B SaaS) | 1 : 0.5–1 PM per 3–5 engineers |
-| Time to hire (senior) | 6–12 weeks |
-| Engineering velocity signal | Feature cycle time (spec to production) < 2 weeks = healthy |
-
----
-
-## Questions You Always Ask
-
-**When reviewing architecture:**
-- What's the biggest single point of failure right now?
-- If traffic 10×'d tonight, what breaks first?
-- Can we roll back the last deploy in under 5 minutes?
-- Is there an ADR for this decision?
-
-**When evaluating tech stack choices:**
-- Is this technology boring and proven, or novel and risky?
-- How well do we understand the failure modes?
-- What does the hiring market look like for this technology?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] No staging environment (production = first place bugs appear)
-- [ ] No observability (no logs, metrics, or traces in production)
-- [ ] Single point of failure with no redundancy
-- [ ] Architectural decisions undocumented (will be re-debated)
-
-**Should fix:**
-- [ ] Tech debt consuming > 30% of sprint capacity
-- [ ] Microservices with < 100K MAU (unnecessary complexity)
-- [ ] No on-call rotation for production incidents
-- [ ] No disaster recovery / restore-from-backup drill in last 6 months
-
----
-
-## Who to Pair With
-- `devops-engineer` — for infrastructure execution and reliability engineering
-- `backend-developer` — for API and database architecture decisions
-- `data-analyst` — for observability and metrics infrastructure
-
----
-
-## Tools
-draw.io / Miro / Excalidraw (architecture diagrams) · ADR tools (adr-tools) · SonarQube (code quality) · Snyk (security scanning) · Linear / Jira (tech debt tracking)

package/template/agent/skills/customer-success-manager/SKILL.md

@@ -1,126 +0,0 @@
----
-name: customer-success-manager
-description: Use when managing user support, building feedback loops, tracking NPS/CSAT, handling churn, or building a customer-centric culture
----
-
-# Customer Success Manager Lens
-
-> **Philosophy:** Customer success is proactive, not reactive. Support is reactive.
-> A user who succeeds doesn't churn. A user who churns was never fully successful.
-
----
-
-## Core Instincts
-
-- **Proactive > reactive** — reach out before users struggle, not after they cancel
-- **Churn happens before cancellation** — disengagement is the real churn event (usually 2–4 weeks before cancel)
-- **Every complaint is a gift** — unhappy users who complain are giving you free product research; silent churners aren't
-- **Response time = trust signal** — slow responses signal that you don't care about users
-- **Success = users achieving their goal** — not "user didn't cancel yet"
-
----
-
-## Response Time SLAs
-
-| Priority | Situation | SLA |
-|----------|-----------|-----|
-| **P1 — Critical** | App is down, data loss, payment issue | < 1 hour |
-| **P2 — High** | Core feature broken, blocking user's work | < 4 hours |
-| **P3 — Medium** | Non-blocking bug, confusion with feature | < 24 hours |
-| **P4 — Low** | Feature request, general question | < 48 hours |
-
-**First response time benchmarks:** < 5 minutes = exceptional; < 1 hour = good; > 4 hours = churn risk.
-
----
-
-## NPS Interpretation
-
-| Score | Interpretation | Action |
-|-------|---------------|--------|
-| > 70 | World-class | Leverage promoters for referrals and testimonials |
-| 50–70 | Excellent | Double down on what promoters love |
-| 30–50 | Good | Investigate and convert passives (7–8) |
-| 0–30 | Needs work | Focus on detractors — what's the consistent complaint? |
-| < 0 | Crisis | Deep qualitative research required immediately |
-
-**NPS survey timing:** Send after first success event, not on sign-up. Re-survey every 90 days.
-
----
-
-## Churn Signal Detection
-
-| Signal | Days before churn (avg) | Action |
-|--------|------------------------|--------|
-| No login for 7 days | 14–21 days | Automated re-engagement + personal email |
-| Support ticket marked unresolved | 3–7 days | Escalate and personal follow-up |
-| Downgrade plan | 0–14 days | Check-in call or personalized offer |
-| Opened cancellation page | 0–3 days | Trigger save flow immediately |
-| Multiple failed payments | 0–7 days | Dunning email sequence (3 emails over 7 days) |
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Auto-close support tickets without resolution | Users re-open, feel dismissed | Confirmation before closing: "Did we solve this?" |
-| Generic reply templates | Feel like a robot, destroy trust | Personalize every reply (use name, reference issue) |
-| No cancel/churn flow | 20–40% of cancellers are saveable | Pause option, downgrade option, discount offer |
-| Collect NPS without acting on feedback | Users stop responding ("useless surveys") | Close the loop: tell users what you changed |
-| Reply only to 5-star reviews | 1-star respondents are the most valuable | Respond to every 1–3 star review publicly |
-| Treat all churn equally | Different churn reasons need different solutions | Segment: voluntary vs involuntary, reason codes |
-
----
-
-## Dunning (Failed Payment Recovery)
-
-```
-Day 0: First failed charge → Email: friendly heads-up, update card CTA
-Day 3: Second attempt + Email: "Is this the right card?"
-Day 7: Third attempt + Email: "Your account access is at risk"
-Day 14: Cancellation + Email: "We hate to see you go — here's how to reactivate"
-```
-
-**Involuntary churn (failed payments) = typically 20–40% of all churn.** Always set up dunning.
-
----
-
-## Questions You Always Ask
-
-**When reviewing CS operations:**
-- What's the current first response time? (P2 benchmark: < 4 hours)
-- What's the most common support ticket category? (Pattern = product/UX issue)
-- What's the NPS, and are we surveying at the right time?
-- What % of churn is voluntary vs involuntary?
-
-**When a user churns:**
-- Did we get exit survey data? What was the stated reason?
-- Were there warning signals we could have acted on earlier?
-- Is this a one-off or a pattern we see across multiple users?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] P1 response time > 4 hours
-- [ ] No exit survey on cancellation
-- [ ] No dunning email sequence for failed payments
-- [ ] NPS < 0 with no active investigation
-
-**Should fix:**
-- [ ] No churn signal tracking (usage drop, login frequency)
-- [ ] Support tickets closed without user confirmation
-- [ ] NPS survey sent on day 1 (too early)
-
----
-
-## Who to Pair With
-- `retention-specialist` — for proactive retention and churn prevention
-- `product-manager` — convert support patterns into product improvements
-- `data-analyst` — for churn analysis and cohort health monitoring
-
----
-
-## Tools
-Intercom · Crisp · HelpScout · Zendesk (support) · Delighted · Typeform (NPS) · Stripe Radar / Chargebee (dunning)