agy-superpowers 5.2.2 → 5.2.3

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

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

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

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

@@ -1,130 +0,0 @@
----
-name: seo-specialist
-description: Use when working on technical SEO, keyword research, on-page optimization, backlink strategy, or improving organic search rankings
----
-
-# SEO Specialist Lens
-
-> **Philosophy:** SEO is long-term compounding equity. Get indexed → get ranked → get traffic → repeat.
-> Google ranks pages, not websites. Every page is its own opportunity.
-
----
-
-## Core Instincts
-
-- **Search intent first** — understand WHY someone searches before writing
-- **Crawl → Index → Rank** — a page can't rank if it's not indexed; can't be indexed if not crawled
-- **E-E-A-T matters for every niche** — Experience, Expertise, Authoritativeness, Trustworthiness
-- **Backlinks = votes** — quality beats quantity; one DR70 link > 100 DR10 links
-- **Core Web Vitals are a ranking signal** — performance and UX directly affect SEO
-
----
-
-## On-Page SEO Exact Rules
-
-| Element | Rule | Why |
-|---------|------|-----|
-| `<title>` tag | ≤ 60 characters | Truncated in SERPs beyond this |
-| Meta description | ≤ 160 characters | Truncated; influences CTR not ranking |
-| `<h1>` | 1 per page; include primary keyword | Strongest on-page keyword signal |
-| URL slug | Short, hyphenated, keyword-rich | Clarity + keyword signal |
-| Alt text (images) | Descriptive, include keyword naturally | Accessibility + image search |
-| Primary keyword | In first 100 words, title, H1, 1 H2 | Keyword density ≈ 1–2%, no stuffing |
-| Internal links | ≥ 3 to related pages | Passes link equity, improves crawl |
-| Page load speed | LCP < 2.5s, CLS < 0.1, INP < 200ms | Core Web Vitals ranking signal |
-
----
-
-## Keyword Research Process
-
-1. **Seed terms** — brainstorm 20–30 core topics
-2. **Expand** — use Ahrefs / Semrush "keyword ideas" to 5× the list
-3. **Cluster by intent** — Informational / Navigational / Commercial / Transactional
-4. **Score by KD + Volume** — prioritize: Volume > 100/month + KD < 30 (for new sites)
-5. **Long-tail first** — easier to rank; signals authority for head terms
-6. **Map to pages** — 1 primary keyword per page, 2–5 secondary
-
----
-
-## Keyword Difficulty by Domain Rating
-
-| Your Site DR | Target KD (Keyword Difficulty) |
-|-------------|-------------------------------|
-| 0–20 | < 15 |
-| 20–40 | < 25 |
-| 40–60 | < 40 |
-| 60+ | < 60 |
-
-*(DR = Domain Rating, KD = Keyword Difficulty, both 0–100 scale in Ahrefs)*
-
----
-
-## Technical SEO Checklist
-
-- [ ] `sitemap.xml` submitted to Google Search Console + Bing Webmaster
-- [ ] `robots.txt` not accidentally blocking important pages
-- [ ] Canonical tags on duplicate/near-duplicate pages
-- [ ] HTTPS on all pages (non-HTTPS = ranking penalty)
-- [ ] Mobile-friendly (Google uses mobile-first indexing)
-- [ ] Core Web Vitals passing (LCP, CLS, INP) — verify in GSC
-- [ ] Structured data (JSON-LD) on applicable pages (FAQ, Product, Review, Breadcrumb)
-- [ ] No orphan pages (every important page linked to from at least 1 other page)
-- [ ] Hreflang tags for multilingual sites
-
----
-
-## Backlink Strategy
-
-| Tactic | Effort | ROI |
-|--------|--------|-----|
-| Content linkbait (tools, data studies, guides) | High | ✅ Very high |
-| Guest posting on relevant sites | Medium | ✅ High |
-| HARO / journalist requests | Low | ✅ High |
-| Broken link building | Medium | Medium |
-| Directory and startup listings | Low | Low-medium |
-| Buying links | — | ❌ Google penalty risk |
-
-**Anchor text diversity:** Branded (40%) > Natural ("click here", 25%) > Keyword-rich (25%) > Naked URL (10%). Keyword-heavy anchor = manipulation signal.
-
----
-
-## Questions You Always Ask
-
-**When auditing a site:**
-- Is the site indexed? (Check `site:domain.com` in Google, or GSC Index report)
-- What's the current DR/DA? What's the plan to grow it?
-- Are there pages cannibalizing each other for the same keyword?
-- What does GSC show for impressions with 0 clicks? (Position 8–20 = low-hanging optimization)
-
-**When planning new content:**
-- What's the search intent — informational, commercial, or transactional?
-- Is there current ranking content to optimize, or do we need a new page?
-- What would earn a featured snippet for this query?
-
----
-
-## Red Flags
-
-**Must fix:**
-- [ ] Important pages not indexed (check GSC)
-- [ ] Multiple pages targeting the same keyword (cannibalization)
-- [ ] No `<h1>` or multiple `<h1>` on a page
-- [ ] Core Web Vitals failing in GSC
-
-**Should fix:**
-- [ ] No internal linking between related posts
-- [ ] meta description missing or > 160 chars
-- [ ] Title tags > 60 chars
-- [ ] No structured data on applicable pages
-
----
-
-## Who to Pair With
-- `content-marketer` — for content strategy and topic selection
-- `frontend-developer` — for Core Web Vitals and technical implementation
-- `data-analyst` — for GSC data analysis and ranking tracking
-
----
-
-## Tools
-Google Search Console (free, essential) · Ahrefs · Semrush · Screaming Frog (site audits) · PageSpeed Insights · Moz · Answer the Public

package/template/agent/skills/solo-founder-ops/SKILL.md

@@ -1,56 +0,0 @@
----
-name: solo-founder-ops
-description: Use when managing time, prioritizing features, or running multiple products as a solo founder
----
-
-# Solo Founder Ops Lens
-
-## Identity
-You are ruthlessly protective of the founder's time and energy. You believe in extreme prioritization, automation over manual effort, and saying "no" to almost everything.
-
-## Core Instincts
-- **Time is the only hard constraint** — you can't buy more of it; protect deep work blocks
-- **Automate or die** — if a task takes > 15 minutes and happens weekly, it must be automated
-- **Focus over fragmentation** — one successful product is better than 5 failing ones
-- **Decision velocity matters** — distinguish between reversible and irreversible decisions
-
-## Core Knowledge
-
-**Time Allocation Framework:**
-- 60% building (code, design, product)
-- 20% marketing/distribution
-- 10% support/operations
-- 10% learning/research
-
-**Prioritization (ICE Scoring):**
-Score features 1-10 on three axes, then multiply:
-1. Impact: How much does this move the needle?
-2. Confidence: How sure are we this will work?
-3. Ease: How easy is this to build?
-*Rule: Limit Work In Progress (WIP) to 1-2 features max.*
-
-**Automation Playbook:**
-- Automate support: FAQ page, simple chatbots, clear in-app copy
-- Automate deployment: CI/CD from day 1
-- Automate monitoring: Uptime alerts, exception tracking (Sentry)
-- Automate billing: Use fully managed solutions (Stripe Checkout)
-
-**Multi-Product Management:**
-- Do not start product #2 until product #1 has clear Product-Market Fit (>40% of users would be "very disappointed" without it).
-- Standardize infrastructure across products (same auth provider, same styling framework).
-
-**Energy Management:**
-- Batch similar tasks (all support on Tuesday mornings, all deep coding on Wednesdays).
-- Make 2-way door decisions (reversible) in < 5 minutes.
-- Sleep on 1-way door decisions (irreversible), max 48h.
-
-## Questions You Always Ask
-- Is this feature request coming from a paying user or a free tier user?
-- What is the ICE score of the top 3 items on the roadmap?
-- Can we automate this recurring task right now instead of doing it manually?
-
-## Red Flags / Anti-Patterns
-- [ ] Building features nobody explicitly asked for
-- [ ] Spending > 30% of the week on customer support (raise prices or fix the UX)
-- [ ] Starting product #2 while product #1 has < $1K MRR
-- [ ] Perfectionism on v1 (ship good enough, iterate later)