agy-superpowers 5.0.6 → 5.0.8

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

@@ -0,0 +1,105 @@
+---
+name: product-manager
+description: Use when defining product requirements, prioritizing features, planning a roadmap, validating user problems, or making build/buy/don't-build decisions
+---
+
+# Product Manager Lens
+
+> **Philosophy:** Build outcomes, not outputs. Ship learning, not just features.
+> The best feature is often the one you decide not to build.
+
+---
+
+## ⚠️ ASK BEFORE ASSUMING
+
+| What | Why it matters |
+|------|----------------|
+| **Stage?** Pre-PMF / Post-PMF / Scaling | Changes everything about what to build |
+| **Who is the user?** | Can't prioritize without knowing whose problem |
+| **What outcome matters?** Revenue / retention / activation | Determines what "done" looks like |
+| **Existing data?** | Don't hypothesize what you can measure |
+
+---
+
+## Core Instincts
+
+- **Jobs-to-be-done (JTBD)** — users don't want features; they want to make progress in their lives
+- **Outcome over output** — "MAU +20%" beats "shipped 10 features"
+- **Pareto ruthlessness** — 20% of features deliver 80% of value; cut the rest
+- **Small bets, fast learning** — ship to learn, not to finish
+- **Pre-PMF: talk to users; post-PMF: read the data**
+
+---
+
+## Prioritization Frameworks
+
+| Framework | When to use |
+|-----------|-------------|
+| **ICE** (Impact × Confidence × Ease) | Quick scoring across many ideas |
+| **RICE** (Reach × Impact × Confidence ÷ Effort) | When reach varies significantly |
+| **MoSCoW** (Must/Should/Could/Won't) | Scoping a release |
+| **Opportunity Scoring** | When you have survey data on importance vs satisfaction |
+
+**Indie hacker rule:** If a feature doesn't directly help activation, retention, or revenue — it's probably a "Won't" for now.
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| Build based on one user request | 1 user ≠ your market | Find the pattern across 5+ interviews |
+| Big bang launch | Months of work, one chance to be right | Shape → Bet → Ship → Learn loop |
+| Vanity metrics as goals | Page views don't pay rent | Retention, activation, revenue |
+| Feature factory (output focus) | Team ships but nothing improves | Set outcome targets, measure impact |
+| Build before validating | Wasted dev weeks | Fake door test, landing page, prototype first |
+| Roadmap spans > 3 months | World changes faster than plans | 6-week cycles max for indie hackers |
+
+---
+
+## Questions You Always Ask
+
+**When defining a feature:**
+- What job is the user trying to get done? What's the progress they want to make?
+- What's the smallest thing we can ship to learn whether this matters?
+- How will we know if this worked? What metric moves?
+- What do we NOT build as a result of building this?
+
+**When reviewing a backlog:**
+- Is this tied to a measurable outcome?
+- Have we talked to users about this problem recently?
+- What happens if we don't build this?
+
+---
+
+## Red Flags
+
+**Must address:**
+- [ ] No acceptance criteria on tickets ("done" is undefined)
+- [ ] Features queued without a linked success metric
+- [ ] No user research backing a major feature bet
+- [ ] Roadmap has no "don't build" list
+
+**Should address:**
+- [ ] Sprint reviews with no outcome data (only feature demos)
+- [ ] No documented JTBD for core user segments
+- [ ] Team can't articulate current North Star Metric
+
+---
+
+## Who to Pair With
+- `copywriter` — to translate features into user-facing language
+- `growth-hacker` — for activation and acquisition loop design
+- `data-analyst` — for outcome measurement and funnel analysis
+
+---
+
+## Key Formulas
+
+```
+North Star Metric = 1 metric that best represents delivered value to users
+
+Activation rate = users who hit "aha moment" / total signups
+Retention = users still active at day N / users who signed up N days ago
+PMF signal = >40% of users would be "very disappointed" if product disappeared (Sean Ellis test)
+```

package/template/agent/skills/real-time-features/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: real-time-features
+description: Use when implementing WebSockets, Server-Sent Events (SSE), live collaboration, presence indicators, real-time notifications, or choosing between real-time transport options
+---
+
+# Real-Time Features Lens
+
+> **Philosophy:** Real-time is expensive infrastructure. Use it only where it's perceptibly better than polling.
+> The cheapest real-time solution is a fast refresh interval with good UX.
+
+---
+
+## Core Instincts
+
+- **Start with polling** — 5-second polling covers 90% of "live" use cases with zero infra complexity
+- **SSE before WebSockets** — SSE is simpler, HTTP/2-compatible, easy to scale; use WebSockets only for bidirectional needs
+- **Connection lifecycle is state** — track connect/disconnect, handle reconnects, never assume connection is alive
+- **Scale out = sticky sessions or pub/sub** — WebSockets break horizontal scaling without Redis Pub/Sub or a broker
+- **Real-time is optional** — always design a fallback (last-write-wins, reconciliation on reconnect)
+
+---
+
+## Technology Selection
+
+```
+Which real-time tech to use?
+
+Need bidirectional (client AND server send)?
+├── YES → WebSocket
+│         (chat, collaborative editing, gaming, live cursors)
+└── NO → Server-Sent Events (SSE) or Polling
+          │
+          └── Data changes frequently + immediate delivery matters?
+              ├── YES → SSE
+              │         (live notifications, dashboards, feeds)
+              └── NO → Long polling or periodic polling
+                        (< 5 changes/min: just poll every 5s)
+```
+
+---
+
+## Technology Comparison
+
+| Feature | Polling | SSE | WebSocket |
+|---------|---------|-----|-----------|
+| Complexity | ⭐ Low | ⭐⭐ Medium | ⭐⭐⭐ High |
+| Bidirectional | ❌ | ❌ | ✅ |
+| HTTP/2 compatible | ✅ | ✅ | ❌ |
+| Horizontal scaling | ✅ Easy | ⚠️ Sticky sessions | ⚠️ Redis Pub/Sub needed |
+| Firewall / proxy friendly | ✅ | ✅ | ⚠️ Sometimes blocked |
+| Browser reconnect | N/A | ✅ Automatic (EventSource) | Manual |
+| Use case | Dashboards, status | Notifications, feeds | Chat, collab |
+
+---
+
+## SSE Implementation Pattern
+
+```javascript
+// Server (Node.js / Express)
+app.get('/events', (req, res) => {
+  // Auth first!
+  if (!req.user) return res.sendStatus(401);
+
+  res.writeHead(200, {
+    'Content-Type':  'text/event-stream',
+    'Cache-Control': 'no-cache',
+    'Connection':    'keep-alive',
+  });
+
+  // Send keepalive every 15s (prevents proxy timeout at 30s)
+  const keepalive = setInterval(() => res.write(': keepalive\n\n'), 15000);
+
+  // Register client
+  clients.set(req.user.id, res);
+
+  // Cleanup on disconnect
+  req.on('close', () => {
+    clearInterval(keepalive);
+    clients.delete(req.user.id);
+  });
+});
+
+// Push to client
+function pushToUser(userId, event, data) {
+  const client = clients.get(userId);
+  if (client) client.write(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`);
+}
+```
+
+---
+
+## WebSocket Scaling Pattern
+
+```
+Single server: Direct WebSocket connection works fine
+Multi-server:  Client connects to Server A, event fires on Server B
+               → Server B can't reach Server A's client
+               → Solution: Redis Pub/Sub
+
+Architecture:
+  [Client] ←WS→ [Server A] ←→ [Redis Pub/Sub] ←→ [Server B] ←WS→ [Client]
+
+Server publishes to Redis channel:
+  await redis.publish(`user:${userId}`, JSON.stringify(event))
+
+Server subscribes on connect:
+  await redis.subscribe(`user:${userId}`, (message) => {
+    ws.send(message)
+  })
+```
+
+---
+
+## Reconnection & State Reconciliation
+
+```javascript
+// Client-side: always implement reconnect with backoff
+const MAX_RETRIES = 5;
+let retries = 0;
+
+function connect() {
+  const ws = new WebSocket(url);
+  
+  ws.onopen = () => { retries = 0; };
+  
+  ws.onclose = () => {
+    if (retries < MAX_RETRIES) {
+      setTimeout(connect, Math.min(1000 * 2 ** retries, 30000));
+      retries++;
+    }
+  };
+}
+
+// Server-side: on reconnect, send missed events since lastEventId
+// SSE: browser sends Last-Event-ID header automatically
+// WebSocket: client sends lastEventId on connect message
+```
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| WebSocket for unidirectional updates | SSE is simpler for same use case | Use SSE for server→client only |
+| In-memory client registry | Breaks on horizontal scale | Redis Pub/Sub for multi-instance |
+| No keepalive messages | Proxy kills idle connections at 30–60s | Send `: keepalive` every 15s |
+| No reconnect logic on client | Single network hiccup = broken UI | Exponential backoff reconnect |
+| Auth skipped on WebSocket handshake | WS connections are permanent — auth must be first | Auth during HTTP upgrade (before WS established) |
+| Sending all state on every event | Expensive; clients drift on missed events | Send diffs; reconcile on reconnect |
+
+---
+
+## Questions You Always Ask
+
+**When choosing real-time:**
+- Does this require bidirectional communication, or is server→client enough?
+- Would polling every 5–10 seconds give acceptable UX?
+- How many concurrent connections do we expect at peak? (Connection limit planning)
+
+**When implementing:**
+- Is there auth on the WebSocket handshake/SSE endpoint?
+- Is there a keepalive to prevent proxy timeouts?
+- What's the reconnection strategy on the client?
+- How is this scaled across multiple server instances?
+
+---
+
+## Red Flags
+
+**Must fix:**
+- [ ] No auth on WebSocket / SSE endpoint
+- [ ] In-memory client registry on multi-instance deployment
+- [ ] No keepalive (proxy will terminate idle connections)
+
+**Should fix:**
+- [ ] No reconnect logic on client
+- [ ] WebSocket used where SSE would suffice
+- [ ] No strategy for clients that miss events while disconnected
+
+---
+
+## Who to Pair With
+- `backend-developer` — for server architecture and Redis Pub/Sub
+- `frontend-developer` — for client-side connection management
+- `devops-engineer` — for WebSocket-aware load balancer config
+
+---
+
+## Tools
+**Managed:** Supabase Realtime · Pusher · Ably · Liveblocks (collaboration)  
+**Self-hosted:** Socket.IO (WebSocket + SSE fallback) · ws (raw WebSocket)  
+**Browser:** `EventSource` (SSE, built-in) · `WebSocket` (built-in)  
+**Scaling:** Upstash Redis · Redis with ioredis

package/template/agent/skills/retention-specialist/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: retention-specialist
+description: Use when improving user retention, designing onboarding flows, reducing churn, analyzing engagement, or building re-engagement campaigns
+---
+
+# Retention Specialist Lens
+
+> **Philosophy:** Retention is the multiplier on everything else. Double retention = double LTV.
+> Acquisition brings users in; retention determines if your business exists in 12 months.
+
+---
+
+## Core Instincts
+
+- **Retention is a product problem, not a marketing problem** — you can't lifecycle-email your way out of a bad product
+- **Find the aha moment first** — the single action most correlated with long-term retention
+- **Day 1 retention is the most important** — users who don't return on Day 1 rarely return at all
+- **Habit formation takes 21–66 days** — retention strategy must operate over weeks, not days
+- **Segment by engagement tier** — power users, casual users, and at-risk users need different interventions
+
+---
+
+## Retention Benchmarks
+
+### Mobile Apps (by category) — 2024 benchmarks
+
+| Category | D1 (good) | D7 (good) | D30 (good) |
+|----------|-----------|-----------|------------|
+| Games | > 28% | > 12% | > 6% |
+| Finance / Fintech | > 25% | > 16% | > 10% |
+| Education | > 26% | > 16% | > 7% |
+| Entertainment | > 27% | > 16% | > 5% |
+| Health & Fitness | > 25% | > 10% | > 5% |
+| Social / Messaging | > 27% | > 11% | > 6% |
+| Productivity / Utilities | > 24% | > 15% | > 5% |
+
+**Context:** Industry-wide D1 average is ~25–28%; D7 ~13–18%; D30 ~5–8%. Apps hitting D30 > 15% are genuinely strong performers.
+**General rule:** D30 < 5% = investigate immediately. D30 > 12% = strong. D30 > 20% = exceptional.
+
+### SaaS / Web Apps — 2024 benchmarks
+| Metric | Poor | Average | Good |
+|--------|------|---------|------|
+| Monthly churn (B2B SaaS) | > 8% | 3.5–5% | < 2% |
+| Monthly churn (B2C / consumer) | > 10% | 5–8% | < 3% |
+| Annual churn (B2B) | > 60% | 30–50% | < 20% |
+| NPS | < 20 | 30–50 | > 50 |
+
+**Context:** Industry average B2B SaaS monthly churn is ~4.2% (Recurly 2024). "< 2% monthly" is excellent / enterprise-level, not just "good".
+
+---
+
+## Push Notification Benchmarks
+
+| Platform | Average open rate | Good open rate |
+|----------|------------------|---------------|
+| iOS | 3–5% | > 7% |
+| Android | 4–7% | > 10% |
+| Email re-engagement | 10–15% | > 20% |
+
+**Push notification rules:**
+- Personalized > generic (2–3× higher open rate)
+- Time-based (sent at user's local peak usage time) > blast sends
+- Opt-in rate drops if you send > 1 notification/day
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| Lifecycle emails before finding aha moment | Emails can't fix a broken product | Find and shorten path to aha moment first |
+| Generic "come back" push notifications | Low open rate, high unsubscribe | Trigger-based, personalized context |
+| Daily active user target only | DAU ignores depth of engagement | Track DAU + session depth + feature usage |
+| Ignore Day 1 drop-off | 60–80% of users churn on Day 1 | Instrument and fix Day 1 experience first |
+| Same onboarding for all user types | Different users need different paths | Personalize onboarding from first question |
+| Cancel flow with no save attempt | 20–40% of cancellers are saveable | Offer pause, downgrade, or discount before cancel |
+
+---
+
+## Questions You Always Ask
+
+**When diagnosing retention:**
+- What does the Day 1/7/30 retention curve look like? Where's the steepest drop?
+- What's the aha moment, and what % of users reach it in session 1?
+- What do retained users do differently from churned users in week 1?
+
+**When designing retention interventions:**
+- Is this a product problem (users don't understand value) or a habit problem (value understood, not habitual)?
+- What's the churn reason? (Run exit survey — "I didn't use it enough" vs "too expensive" vs "found alternative")
+
+---
+
+## Red Flags
+
+**Must fix:**
+- [ ] Day 1 retention < 20% (broken first experience)
+- [ ] No aha moment defined or instrumented
+- [ ] Monthly churn > 8% with no active investigation
+- [ ] No exit survey / churn reason tracking
+
+**Should fix:**
+- [ ] No push notification strategy (relying only on email)
+- [ ] No in-app re-engagement for users inactive > 7 days
+- [ ] Onboarding identical for all user segments
+- [ ] No cancel flow / save attempt
+
+---
+
+## Who to Pair With
+- `product-manager` — for aha moment and activation event design
+- `growth-hacker` — for AARRR funnel optimization
+- `data-analyst` — for cohort analysis and retention curve modeling
+
+---
+
+## Key Formulas
+
+```
+Retention rate (Day N) = users_still_active_on_day_N / users_who_signed_up_N_days_ago
+Monthly churn          = churned_users_this_month / users_at_start_of_month
+Annual churn           ≈ 1 - (1 - monthly_churn)^12
+NPS                    = % Promoters (9–10) - % Detractors (0–6)
+```

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

@@ -0,0 +1,139 @@
+---
+name: saas-architect
+description: Use when designing multi-tenant SaaS architecture, tenant isolation, data models, or making core infrastructure decisions for a SaaS product
+---
+
+# SaaS Architect Lens
+
+> **Philosophy:** Multi-tenancy is not a feature — it's a fundamental architectural constraint.
+> Every design decision must answer: "Is this tenant-safe?"
+
+---
+
+## Core Instincts
+
+- **Tenant isolation first** — data leaking between tenants is an existential business risk
+- **Design for the tenant, not the user** — every entity in the data model has a `tenant_id`
+- **Shared infrastructure, isolated data** — the sweet spot for indie hackers
+- **Plan the upgrade path** — schema-per-tenant → RLS → shared schema: picking wrong is expensive to change
+- **Hard-delete rarely; soft-delete by default** — audit trails matter in B2B
+
+---
+
+## Tenancy Isolation Models
+
+| Model | Isolation | Cost | Complexity | Best for |
+|-------|-----------|------|------------|----------|
+| **Separate database per tenant** | ✅ Strongest | 💰 Highest | High | Enterprise, regulated industries |
+| **Schema per tenant** (PostgreSQL) | ✅ Strong | 💰 Medium | Medium | Mid-market SaaS |
+| **Row-level security (RLS)** | ✅ Good | 💰 Low | Medium | Indie hacker / SMB SaaS |
+| **Application-level filtering** | ⚠️ Weakest | 💰 Lowest | Low | Prototype only — never production |
+
+**Recommended for indie hackers:** Row-Level Security (RLS) on PostgreSQL (Supabase, Neon). Strong isolation at low cost.
+
+---
+
+## Tenant Data Model Pattern
+
+```sql
+-- Every table must have tenant_id
+CREATE TABLE projects (
+  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  tenant_id   UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
+  name        TEXT NOT NULL,
+  created_at  TIMESTAMPTZ DEFAULT now(),
+  deleted_at  TIMESTAMPTZ  -- soft delete
+);
+
+-- RLS: tenant can only see their own rows
+ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
+CREATE POLICY tenant_isolation ON projects
+  USING (tenant_id = current_setting('app.tenant_id')::UUID);
+
+-- Index tenant_id on EVERY tenant-scoped table
+CREATE INDEX ON projects(tenant_id);
+```
+
+---
+
+## Tenant Routing Patterns
+
+```
+Option 1: Subdomain routing
+  acme.myapp.com → tenant lookup by subdomain → set tenant_id context
+
+Option 2: Path routing
+  myapp.com/acme → extract slug from path → set tenant_id context
+
+Option 3: Custom domain
+  app.acme.com → CNAME → myapp.com → DNS lookup → set tenant_id context
+
+Recommended for indie hackers: Start with subdomain routing; add custom domains when users ask.
+```
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| Application-level tenant filtering only | One missing WHERE clause = data breach | RLS at DB level = defense in depth |
+| Tenant ID in JWT payload, enforced only in app | Bypassed by direct DB access | DB-level enforcement (RLS or schema) |
+| Hard-delete tenant data immediately | Chargebacks, disputes, legal holds | Soft-delete + 30-day retention before purge |
+| No tenant_id index | Full table scan at scale | `CREATE INDEX ON every_table(tenant_id)` |
+| Single shared sequence for IDs | Enumerable IDs expose tenant data volume | UUIDs (v4 or v7) always |
+| Storing cross-tenant references | Breaks isolation, schema nightmare | Denormalize data within tenant boundary |
+
+---
+
+## Tenant Lifecycle Management
+
+```
+Sign up → Create tenant record → Create owner user → Provision trial subscription
+         ↓
+      Active → Upgrade → Downgrade → Cancel → Grace period (30 days) → Purge
+```
+
+**Required tenant states:** `trialing`, `active`, `past_due`, `canceled`, `suspended`
+
+---
+
+## Questions You Always Ask
+
+**When adding a new model:**
+- Does every record in this table belong to a tenant? → Add `tenant_id`
+- Is there an index on `tenant_id`?
+- Does the RLS policy cover this table?
+- What happens when the tenant is deleted/canceled?
+
+**When reviewing a query:**
+- Is `tenant_id` in the WHERE clause? (Even with RLS, explicit filtering = clarity)
+- Could this query return data from another tenant?
+
+---
+
+## Red Flags
+
+**Must fix:**
+- [ ] Tables with user data but no `tenant_id`
+- [ ] Application-level tenant filtering without DB-level enforcement
+- [ ] No index on `tenant_id` columns
+- [ ] Hard-delete on tenant cancellation (no retention period)
+
+**Should fix:**
+- [ ] No soft-delete strategy for tenant-scoped records
+- [ ] Cross-tenant foreign key references
+- [ ] Tenant ID stored as integer (enumerable — use UUID)
+
+---
+
+## Who to Pair With
+- `backend-developer` — for query patterns and migration execution
+- `auth-and-identity` — for tenant-scoped authentication
+- `security-engineer` — for data isolation audit
+- `devops-engineer` — for per-tenant resource provisioning
+
+---
+
+## Tools
+Supabase (RLS built-in) · Neon (branching per tenant possible) · PlanetScale (separate DBs) · Drizzle ORM / Prisma (schema management) · Zod (runtime tenant_id validation)

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

@@ -0,0 +1,133 @@
+---
+name: security-engineer
+description: Use when reviewing app security, setting up authentication, handling user data, ensuring GDPR/App Store compliance, or conducting security audits
+---
+
+# Security Engineer Lens
+
+> **Philosophy:** Security is not a feature you add later — it's a constraint you design around from day one.
+> The cost of a breach is always higher than the cost of prevention.
+
+---
+
+## Core Instincts
+
+- **Principle of least privilege** — every system, user, and API key should have only the permissions it needs
+- **Defense in depth** — multiple layers of security; no single point of failure
+- **Never trust input** — validate and sanitize everything, regardless of source
+- **Secrets are not config** — credentials never live in code, git history, or logs
+- **Privacy by design** — collect only what you need; retain only as long as required
+
+---
+
+## OWASP Top 10 (Most Common Vulnerabilities)
+
+| Rank | Vulnerability | Prevention |
+|------|--------------|------------|
+| A01 | **Broken Access Control** | Enforce auth on every endpoint; deny by default |
+| A02 | **Cryptographic Failures** | Use TLS everywhere; bcrypt/argon2 for passwords |
+| A03 | **Injection** (SQL, NoSQL, OS) | Parameterized queries; never string-concatenate user input into queries |
+| A04 | **Insecure Design** | Threat model during design, not after |
+| A05 | **Security Misconfiguration** | Disable debug in prod; update defaults; least privilege |
+| A06 | **Vulnerable Components** | `npm audit` / `pip audit` regularly; automate with Dependabot |
+| A07 | **Identification and Authentication Failures** | bcrypt cost ≥12; JWT short expiry; PKCE for mobile |
+| A08 | **Software Integrity Failures** | Verify 3rd-party scripts; use SRI for CDN assets |
+| A09 | **Security Logging and Monitoring Failures** | Log security events; never log passwords/tokens/PII |
+| A10 | **SSRF** | Validate/allowlist outbound URLs; block internal network access |
+
+---
+
+## Auth Security Rules
+
+| Concern | Requirement |
+|---------|-------------|
+| Password hashing | `bcrypt` (cost ≥ 12; OWASP minimum is 10, 12 recommended) or `argon2id` — never MD5, SHA1, SHA256 |
+| JWT access token expiry | 15 minutes – 1 hour |
+| JWT refresh token expiry | 7–30 days; rotate on use |
+| Session cookies | `HttpOnly` + `Secure` + `SameSite=Strict` |
+| OAuth for mobile apps | PKCE required (no client_secret in mobile apps) |
+| API keys at rest | Store as SHA-256 hash; show plaintext only at creation |
+| Password reset tokens | Single-use, expire in 15–60 minutes |
+| Rate limiting auth endpoints | Max 5 failed attempts / 15 minutes per IP |
+
+---
+
+## Data Privacy Requirements
+
+### GDPR (EU users)
+- Legal basis required for every data collection (consent, legitimate interest, contract)
+- Privacy policy must be clear, plain language, accessible before sign-up
+- Right to erasure: must be able to delete all user data on request
+- Data breach notification: 72 hours to supervisory authority, "without undue delay" to users
+- Data minimization: only collect what's needed for stated purpose
+
+### App Store (Apple)
+- Privacy Nutrition Label: declare all data collected and its purpose
+- ATT (App Tracking Transparency): required prompt before any cross-app tracking
+- Data linked to user: justify every category collected
+- No collecting device data beyond stated purpose
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| `SELECT *` or raw string SQL | SQL injection risk | Parameterized queries / ORM always |
+| Secrets in `.env` committed to git | git history = permanent leak | `.env.example` only; real secrets in secret manager |
+| MD5 or SHA1 for passwords | Crackable in minutes with rainbow tables | `bcrypt` cost ≥12 or `argon2id` |
+| JWT stored in `localStorage` | XSS attack can steal it | Use `HttpOnly` cookies for JWTs |
+| Disable CORS entirely | Any site can make authenticated requests as your user | Configure CORS allowlist carefully |
+| Verbose error messages in prod | Leaks implementation details | Generic messages to clients; full details in server logs only |
+| No dependency vulnerability scanning | CVEs accumulate silently | Dependabot / Snyk / `npm audit` in CI |
+
+---
+
+## Security Audit Checklist for Indie Hackers
+
+**Authentication:**
+- [ ] Passwords hashed with bcrypt (cost ≥12) or argon2id
+- [ ] Rate limiting on login + password reset endpoints
+- [ ] JWT access tokens expire in < 1 hour
+- [ ] HTTPS enforced everywhere (redirect HTTP → HTTPS)
+
+**Data:**
+- [ ] No PII in logs (emails, names, IP addresses)
+- [ ] User data deletion endpoint exists and works
+- [ ] Database not publicly accessible (behind VPC/firewall)
+- [ ] Backups encrypted at rest
+
+**Dependencies:**
+- [ ] `npm audit` / `pip audit` / `bundle audit` in CI pipeline
+- [ ] No known critical CVEs in production dependencies
+
+**App Store / Privacy:**
+- [ ] Privacy Nutrition Label accurate (iOS)
+- [ ] ATT prompt implemented if tracking cross-app (iOS)
+- [ ] Privacy policy live and linked from app/store listing
+
+---
+
+## Questions You Always Ask
+
+**When adding auth:**
+- What's the token storage strategy? (Avoid localStorage for JWTs)
+- Is the password reset flow single-use and time-limited?
+- Are failed login attempts rate-limited per IP?
+
+**When handling user data:**
+- Is there a legal basis for collecting this data?
+- Can a user request deletion of all their data?
+- Is this data encrypted at rest and in transit?
+
+---
+
+## Who to Pair With
+- `backend-developer` — for auth implementation and API security
+- `devops-engineer` — for infrastructure security and secret management
+- `cto-architect` — for threat modeling and security architecture
+
+---
+
+## Tools
+OWASP ZAP (free scanner) · Snyk · Dependabot · Burp Suite (manual testing) · HaveIBeenPwned API (compromised password check) · Neon / Supabase (managed DB with encryption at rest)