agy-superpowers 5.2.1 → 5.2.3

package/template/agent/skills/app-store-optimizer/SKILL.md

@@ -1,127 +0,0 @@
----
-name: app-store-optimizer
-description: Use when working on App Store / Google Play listing optimization, keyword strategy, screenshots, ratings, or app store A/B testing
----
-
-# App Store Optimizer Lens
-
-> **Philosophy:** ASO is SEO for app stores. Discoverability + conversion = downloads.
-> Most apps lose 60%+ of potential downloads to a weak listing, not a weak product.
-
----
-
-## Core Instincts
-
-- **Title keyword is the highest-ranking signal** — include your primary keyword in the title
-- **First 3 screenshots convert or kill** — most users never scroll past them
-- **Ratings velocity > average rating** — a burst of fresh 5-stars beats a stale 4.8
-- **Keyword field is invisible to users but critical to ranking** — use every character
-- **Localize for top markets** — EN + your top 3 markets = 80% of opportunity
-
----
-
-## Platform Limits (Know These Cold)
-
-### iOS App Store
-| Field | Limit | Notes |
-|-------|-------|-------|
-| Title | **30 chars** | Primary keyword weight = 2× |
-| Subtitle | **30 chars** | Secondary keyword, benefit-focused |
-| Keywords | **100 chars** | Comma-separated, no spaces, no repeats from title |
-| Description | **4000 chars** | First **255 chars** shown before "more" |
-| Promo text | **170 chars** | Updates without review; use for time-limited offers |
-| Screenshots | Up to **10** | Sizes vary by device; first 3 drive 80% of conversion |
-| Preview video | **15–30 seconds** | First 3 seconds must hook without sound |
-
-### Google Play
-| Field | Limit | Notes |
-|-------|-------|-------|
-| Title | **30 chars** | Keyword-rich |
-| Short description | **80 chars** | Shown in search; make it scannable |
-| Long description | **4000 chars** | First 167 chars auto-expanded; repeat keyword 3–5× |
-| Screenshots | Up to **8** | 16:9 or 9:16 preferred |
-| Feature graphic | **1024 × 500px** | Shown in featured slots |
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Title = just the brand name | Zero keyword signal | Brand + primary keyword (e.g., "Todoist: To-Do List & Tasks") |
-| Leave keywords field blank (iOS) | 100 chars of free ranking wasted | Fill every character with non-title keywords |
-| First screenshot = app logo splash | Users bounce, no context | First screenshot = core value prop as hero text |
-| Ask for review on first open | Users hate it, Apple rejects manipulative prompts | Ask after a success action (task completed, streak hit) |
-| Ignore 1-star reviews | Review responses shown publicly; silence = neglect | Respond within 48h; apologize + explain fix |
-| Use keywords that appear in title (iOS) | Apple ignores duplicates | Every keyword field word must be unique |
-| Generic description | No differentiation, no keywords | Keyword-rich first paragraph, benefit bullets |
-
----
-
-## Keyword Research Process
-
-1. **Seed keywords** — brainstorm 20–30 relevant terms
-2. **Competitor analysis** — check top 5 competitor titles/subtitles
-3. **Volume + difficulty** — use Sensor Tower / AppTweak / AppFollow to score
-4. **Priority matrix** — High volume + Low difficulty = target first
-5. **Long-tail focus** — easier to rank for "meditation app for anxiety" than "meditation"
-6. **Update every 60–90 days** — track rank changes, iterate
-
----
-
-## Ratings Strategy
-
-**When to prompt:** After user completes a meaningful success action, NOT on launch.
-- Good triggers: completed task, reached streak, finished session, saved something
-- Bad triggers: app open, screen view, after onboarding
-
-**Target benchmarks:**
-| Metric | Floor | Target |
-|--------|-------|--------|
-| Average rating | > 4.0 | > 4.5 |
-| Review count (for featuring) | > 100 | > 500 |
-| Response rate to 1-star | — | > 80% within 48h |
-
-**Recovering from bad ratings:** Respond to every 1-star, release fix quickly, request updated review from resolved users.
-
----
-
-## Questions You Always Ask
-
-**When auditing a listing:**
-- Is the primary keyword in the title?
-- Do the first 3 screenshots tell a complete story without reading any text?
-- Is the keyword field 100% utilized (iOS)?
-- What's the current conversion rate from impression to download? (Benchmark: 3–7%)
-
-**When planning ASO strategy:**
-- Which markets are we localizing for?
-- What keywords are competitors ranking for that we're missing?
-- When was the last time we A/B tested screenshots?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] Title is brand name only (no keyword)
-- [ ] iOS keyword field < 90 characters used
-- [ ] First screenshot is a splash screen or abstract illustration
-- [ ] No response to 1-star reviews
-
-**Should fix:**
-- [ ] Description first 255 chars (iOS) / 167 chars (Play) not benefit-focused
-- [ ] No preview video
-- [ ] Listing not localized for top 3 markets
-
----
-
-## Who to Pair With
-- `copywriter` — for listing copy strategy
-- `growth-hacker` — for launch burst strategy (ratings velocity)
-- `conversion-optimizer` — for screenshot A/B testing
-
----
-
-## Tools
-AppFollow · Sensor Tower · AppTweak · AppFigures · MobileAction · Apple Search Ads Intelligence

package/template/agent/skills/auth-and-identity/SKILL.md

@@ -1,167 +0,0 @@
----
-name: auth-and-identity
-description: Use when implementing authentication, authorization, SSO/SAML/OIDC, multi-tenant identity, session management, or role-based access control for a SaaS product
----
-
-# Auth & Identity Lens
-
-> **Philosophy:** Authentication proves who you are. Authorization proves what you can do.
-> Mixing them up is the most common source of privilege escalation bugs.
-
----
-
-## Core Instincts
-
-- **AuthN ≠ AuthZ** — always handle them as separate concerns
-- **Every request must be authenticated AND authorized** — auth middleware is not authorization
-- **Tenant context must be established on every request** — after AuthN, before any DB query
-- **Fail closed** — when in doubt, deny; never default to permissive
-- **Never roll your own crypto** — use proven libraries and protocols
-
----
-
-## Multi-Tenant Auth Flow
-
-```
-Request arrives →
-1. Verify token/session (AuthN) → get user_id
-2. Load user + tenant membership → get tenant_id, role
-3. Set tenant context (RLS / app context)
-4. Check permission for this route/resource (AuthZ)
-5. Execute request
-```
-
-**Order matters:** If you skip step 3, RLS doesn't know which tenant. If you skip step 4, any authenticated user can do anything.
-
----
-
-## Auth Strategy Selection
-
-| Method | Best for | Not for |
-|--------|----------|---------|
-| **JWT (stateless)** | Stateless APIs, microservices | When you need instant revocation |
-| **Session cookie** | Web apps, SSR | Mobile-first or API-only |
-| **API key** | Machine-to-machine, developer APIs | User-facing login |
-| **SAML 2.0** | Enterprise SSO (Okta, Azure AD) | Consumer apps |
-| **OIDC / OAuth 2.0** | Social login, federated identity | Internal-only systems |
-
-**Indie hacker default:** Session cookies for web (HttpOnly, Secure, SameSite=Strict) + JWT for API endpoints.
-
----
-
-## JWT Rules
-
-```
-Access token:
-- Expiry: 15 minutes (short-lived; compromised → limited damage window)
-- Payload: user_id, tenant_id, role, exp — NO sensitive data
-- Store: Memory (never localStorage) or HttpOnly cookie
-
-Refresh token:
-- Expiry: 7–30 days
-- Store: HttpOnly cookie ONLY
-- Rotate on every use (refresh token rotation)
-- Invalidate all refresh tokens on password change/logout all
-
-Signing:
-- Algorithm: RS256 (asymmetric, allows public verification) or HS256 (simpler, shared secret)
-- Secret: ≥ 32 random bytes; rotate if compromised (support multiple valid secrets during rotation)
-```
-
----
-
-## RBAC Pattern (Role-Based Access Control)
-
-```typescript
-// Roles per tenant membership (not global)
-type TenantRole = 'owner' | 'admin' | 'member' | 'viewer';
-
-// Permissions defined as capability strings
-const PERMISSIONS = {
-  owner:  ['billing:manage', 'members:manage', 'data:delete', 'data:write', 'data:read'],
-  admin:  ['members:manage', 'data:write', 'data:read'],
-  member: ['data:write', 'data:read'],
-  viewer: ['data:read'],
-} satisfies Record<TenantRole, string[]>;
-
-// Check at every protected route/action
-function can(user: User, permission: string): boolean {
-  return PERMISSIONS[user.tenantRole]?.includes(permission) ?? false;
-}
-```
-
----
-
-## SSO / SAML Integration (Enterprise)
-
-```
-When to build SAML:
-- Enterprise customers require it (Okta, Azure AD, Google Workspace)
-- Single "SAML" request in a deal is worth building immediately
-
-Implementation options for indie hackers:
-1. WorkOS — $0 to start, pay per enterprise connection; fastest path
-2. Auth0 / Clerk — SAML add-on; higher cost at scale
-3. Roll your own — samlify / passport-saml; significant complexity
-
-SAML Flow:
-  User → Your SP (Service Provider) → IdP (Okta/AzureAD) → SAML assertion → SP → Session
-```
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| JWT in `localStorage` | XSS attack steals token, unlimited access | `HttpOnly` cookie |
-| Long-lived access tokens (> 1 hour) | Compromised token = long exposure window | 15 min expiry + refresh token rotation |
-| Storing passwords as anything but bcrypt/argon2id | Rainbow table crack in seconds | bcrypt cost ≥12 or argon2id |
-| Checking auth at route level only | Bypassed by internal calls | Check permissions at the service/data layer |
-| Global admin role without per-tenant scope | One compromised admin = all tenants affected | Admin role always scoped to a tenant |
-| No rate limiting on auth endpoints | Brute force, credential stuffing | Max 5 attempts / 15 min per IP |
-| Email as unique identifier across tenants | Same email in multiple tenants = collision | `(email, tenant_id)` composite unique |
-
----
-
-## Questions You Always Ask
-
-**When designing auth:**
-- Is tenant context established before any DB query happens?
-- Does AuthZ happen at the service layer, not just route middleware?
-- Are refresh tokens rotated on every use?
-- What's the logout flow? Does it invalidate server-side session/refresh token?
-
-**When adding a new role or permission:**
-- Is this the least privilege needed for this action?
-- Have we tested that a lower-privileged role cannot access this?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] JWT stored in `localStorage`
-- [ ] No tenant_id in auth context (tenant isolation can't work)
-- [ ] Authorization only checked at route level (not service/data layer)
-- [ ] No rate limiting on `/login`, `/forgot-password`, `/reset-password`
-
-**Should fix:**
-- [ ] Refresh tokens not rotated on use
-- [ ] No MFA option for admin/owner roles
-- [ ] Email uniqueness checked globally (not per-tenant)
-
----
-
-## Who to Pair With
-- `saas-architect` — for tenant context in data model
-- `security-engineer` — for token storage and auth security audit
-- `backend-developer` — for middleware and session management
-
----
-
-## Tools
-**Hosted auth:** Clerk · Auth0 · Supabase Auth · Firebase Auth  
-**Self-hosted:** NextAuth.js / Auth.js · Lucia · Better Auth  
-**Enterprise SSO:** WorkOS · Boxyhq (open source)  
-**Libraries:** `jose` (JWT) · `bcrypt` / `argon2` (passwords) · `samlify` (SAML)

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

@@ -1,148 +0,0 @@
----
-name: backend-developer
-description: Use when designing APIs, working on server-side logic, database schemas, or reviewing backend code — regardless of stack
----
-
-# Backend Developer Lens
-
-> **Philosophy:** Design for contracts, failure modes, and observability.
-> If you can't observe it failing, you can't fix it. If you can't roll it back, don't ship it.
-
----
-
-## ⚠️ ASK BEFORE ASSUMING
-
-If the stack is unspecified, **DO NOT default to Express + MongoDB**. Ask:
-
-| What | Why it matters |
-|------|----------------|
-| **Language/framework?** Node / Python / Go / etc. | Determines idioms and patterns |
-| **Database?** SQL / NoSQL / in-memory | Shapes the entire data model |
-| **Auth model?** JWT / session / API key / OAuth | Must be decided before the first endpoint |
-| **Deployment?** Container / serverless / VM | Affects scaling, connection pooling |
-| **Existing API contract?** | Determines versioning constraints |
-
-When stack is unspecified, assume Node.js + PostgreSQL + REST.
-
----
-
-## Core Instincts
-
-- **API contracts are public** — breaking changes require versioning; consumers break silently
-- **N+1 is always lurking** — query patterns that work in dev collapse at scale
-- **Fail loudly in dev, gracefully in prod** — errors must be observable; silent failures are unacceptable
-- **Auth is load-bearing** — authentication and authorization must be in the design from the start
-- **Schema changes are permanent** — migrations must be backward-compatible; rollback path required
-
----
-
-## Performance & Scale Thresholds
-
-| Metric | Target | Investigate |
-|--------|--------|-------------|
-| API response time (p99) | < 500ms | > 1s |
-| Database query time (p99) | < 100ms | > 500ms |
-| DB connection pool size | CPU cores × 2–4 | > 100 (connection thrash) |
-| Max payload size (JSON) | < 1MB | > 5MB → stream or paginate |
-| Background job retry limit | 3–5 retries | Unbounded = infinite loops |
-| Rate limit (public API) | 60–100 req/min per IP | Application-specific |
-| Pagination page size | 20–100 items | > 500 → server load + slow clients |
-
----
-
-## ❌ Anti-Patterns to Avoid
-
-| ❌ NEVER DO | Why | ✅ DO INSTEAD |
-|------------|-----|--------------|
-| Database queries in a loop | N+1 = catastrophic at scale | Batch query with `IN (...)`, JOIN, or eager load |
-| Silent `catch {}` blocks | Failures invisible, impossible to debug | Log with context (req ID, user ID), re-throw or return structured error |
-| Secrets in source code | Leaked via git, logs, stack traces | `process.env` + secret manager (Vault, AWS Secrets Manager) |
-| No input validation | Injection, crashes, bad data in DB | Validate at the API boundary (Zod, Joi, Pydantic, etc.) |
-| No rate limiting on public endpoints | Trivially abused, DDoS surface | Rate limit per IP + per user at gateway or middleware |
-| Schema migration without rollback | One bad deploy = DB emergency | Always write `up` AND `down` migration |
-| Breaking API change without versioning | Consumers silently break in prod | `/v2/` prefix + deprecation headers + sunset date |
-| Business logic in controllers | Untestable, duplicated across routes | Service layer for all business rules |
-| Unbounded queries | Full table scan in prod at 10M rows | Always paginate: `LIMIT` + `OFFSET` or cursor-based |
-| Storing plaintext passwords | One breach = all accounts compromised | `bcrypt` (cost ≥ 12) or `argon2id` |
-
----
-
-## HTTP Status Code Reference
-
-| Situation | Status | Notes |
-|-----------|--------|-------|
-| Success, returns data | 200 | |
-| Created resource | 201 | Include `Location` header |
-| Success, no body | 204 | |
-| Permanent redirect | 301 | Browser caches; use with care |
-| Temporary redirect | 302 | Common for auth flows |
-| Bad input from client | 400 | Include field-level validation errors |
-| Missing / invalid auth token | 401 | Trigger re-auth on client |
-| Valid auth, no permission | 403 | Do NOT reveal resource existence |
-| Resource not found | 404 | |
-| Method not allowed | 405 | Include `Allow` header |
-| Duplicate or state conflict | 409 | Idempotency conflicts, duplicate key |
-| Business rule violation | 422 | Structurally valid, semantically wrong |
-| Rate limit exceeded | 429 | Include `Retry-After` header |
-| Our fault (unhandled error) | 500 | Log full context; return safe message |
-| Upstream service down | 502 / 503 | |
-
----
-
-## Auth Quick Rules
-
-| Concern | Rule |
-|---------|------|
-| JWT expiry | Access token: 15 min–1h. Refresh token: 7–30 days |
-| JWT secret rotation | Rotate on breach; support multiple valid secrets during rotation |
-| Password hashing | `bcrypt` with cost factor ≥ 12, or `argon2id` |
-| API keys | Store as SHA-256 hash; show plaintext only once on creation |
-| Session cookies | `HttpOnly`, `Secure`, `SameSite=Strict` or `Lax` |
-| OAuth PKCE | Required for all public clients (SPAs, mobile apps) |
-
----
-
-## Questions You Always Ask
-
-**When designing APIs:**
-- What's the auth model? Who can call this and how?
-- What happens if a downstream service is unavailable?
-- How does this behave at 10x current load?
-- What gets logged when this fails in production?
-
-**When reviewing database work:**
-- Is this query indexed? What does `EXPLAIN ANALYZE` show at scale?
-- Does this migration have a safe rollback path?
-- Are we handling concurrent writes correctly (race conditions, optimistic locking)?
-- Will this schema change break existing clients before the code deploy?
-
----
-
-## Red Flags in Code Review
-
-**Must fix:**
-- [ ] Missing input validation or sanitization
-- [ ] Silent `catch` blocks (errors swallowed without logging)
-- [ ] N+1 queries (fetching inside loops)
-- [ ] Secrets or credentials in source code or logs
-- [ ] Plaintext password storage
-
-**Should fix:**
-- [ ] No rate limiting on public-facing endpoints
-- [ ] Schema migrations without a rollback (`down`) strategy
-- [ ] Auth logic duplicated across controllers (not centralized in middleware)
-- [ ] Unstructured error responses (no error code, no field references)
-- [ ] Unbounded queries without pagination
-
----
-
-## Async Pattern Selection
-
-| Pattern | Use when |
-|---------|----------|
-| `async/await` | Sequential operations with dependencies |
-| `Promise.all()` | Parallel independent operations (all must succeed) |
-| `Promise.allSettled()` | Parallel where some can fail independently |
-| Message queue (BullMQ, SQS) | Fire-and-forget, retry logic, spike buffering |
-| Cron / scheduler | Periodic background jobs |
-| Streaming | Large payloads, real-time updates, long-running responses |

package/template/agent/skills/bootstrapper-finance/SKILL.md

@@ -1,55 +0,0 @@
----
-name: bootstrapper-finance
-description: Use when tracking MRR, calculating runway, making financial decisions for a solo/bootstrapped business, or evaluating "quit your job" timing
----
-
-# Bootstrapper Finance Lens
-
-## Identity
-You are ruthlessly pragmatic about cash flow, runway, and profitability. You treat the indie hacker's personal finances and business finances as a single interconnected system. Survival is the primary goal; thriving comes second.
-
-## Core Instincts
-- **Time is money** — runway is calculated in months of survival, not just bank balances
-- **LTV > CAC** — unit economics must be positive before scaling acquisition
-- **Free until PMF** — minimize fixed costs until Product-Market Fit is proven
-- **Cash flow is king** — annual subscriptions are the lifeblood of a bootstrapped SaaS
-
-## Core Knowledge
-
-**Runway Calculator:**
-`months_remaining = (savings + projected_income) / monthly_burn`
-- Include personal living expenses, server costs, and tool subscriptions in the burn rate.
-
-**"Quit Your Job" Framework:**
-Safe to quit when:
-1. MRR ≥ 1.5× personal monthly baseline expenses
-2. This MRR has been sustained for 3+ consecutive months
-3. 6+ months of living expenses saved as a cash buffer
-4. The growth trend is upward, not flat
-
-**Expense Prioritization for Indie:**
-- **Worth paying for:** Domain ($12/yr), hosting (free tier → $20/mo), email service ($0-20/mo), error tracking ($0-26/mo)
-- **Free alternatives exist:** Analytics (Plausible self-hosted), design (Figma free tier), CI/CD (GitHub Actions)
-- **Don't pay until PMF:** Paid ads, premium enterprise tools, heavy full-featured analytics suites
-
-**Revenue Milestones:**
-- **$100 MRR:** You validated that people will pull out their credit cards.
-- **$1K MRR:** It's a real business. Focus on reducing churn.
-- **$5K MRR:** Could cover baseline living expenses in many regions.
-- **$10K MRR:** Comfortable indie lifestyle. Time to consider scaling or going full-time.
-
-**Tax Basics (Not Legal Advice):**
-- Track all business expenses strictly.
-- Separate business bank account from day 1.
-- Quarterly estimated taxes (US) / VAT registration thresholds (EU).
-
-## Questions You Always Ask
-- What is the current MRR and monthly churn rate?
-- What is the total monthly burn (personal + business)?
-- Are unit economics (LTV:CAC) positive on ad spend?
-
-## Red Flags / Anti-Patterns
-- [ ] Spending on paid acquisition (ads) before hitting $1K MRR organically
-- [ ] No tracking of monthly expenses vs. revenue
-- [ ] Running at negative unit economics while trying to scale
-- [ ] Quitting a job with < 6 months of runway in cash

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
-```