@kensaurus/skills 0.0.0-stage → 2.1.0

package/skills/plan-privacy-compliance/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: plan-privacy-compliance
+description: >
+  Plan-only audit mapping real personal-data flows to the privacy policy,
+  GDPR, Japan APPI, and store labels. Use when "privacy compliance", "what
+  data do we collect?", "App Store privacy labels", or before a consumer
+  launch.
+license: MIT
+effort: high
+---
+
+# plan-privacy-compliance — Data-flow & legal-surface plan
+
+**Degree of freedom: HIGH** — interpretive inventory and plan. Stay
+**plan-only**. T4 before presenting the burndown.
+
+**Role:** Privacy engineer (operational compliance, not legal advice).
+
+**Task:** Map what the *code* collects, diff it against the written policy and
+store labels, emit `plan-privacy-compliance.md`. **Audit & plan only — no policy
+rewrites, SDK gates, or deletion jobs until each phase is approved.**
+
+**The gap that sinks apps is collection-vs-claimed:** the code gathers more than
+the privacy policy admits, and the store label is wrong.
+
+Not legal advice. This operationalizes common GDPR and Japan APPI
+(個人情報保護法) requirements into engineering findings. Flag genuine ambiguity
+for a lawyer.
+
+## This skill vs neighbors
+
+| Skill | Owns |
+|---|---|
+| **plan-privacy-compliance** (this) | Data inventory, consent timing, deletion/export, store labels |
+| `audit-analytics` | Event taxonomy + whether analytics *fires before consent* |
+| `plan-mobile-readiness` | Submission mechanics (demo account, 2.5.2) — not the data-flow diff |
+| `plan-rls-audit` | Who can *read* rows — not what you promised to collect |
+| `plan-error-handling` | PII in Sentry/logs |
+| `enhance-email-deliverability` | Lawful send / unsubscribe (consent to mail) |
+
+Do **not** fire for "privacy manifest / Data Safety form paperwork only" if the
+user is mid-store-submit → still run this for the *data-flow* half, then
+`plan-mobile-readiness` for the rest.
+
+## How to reason (every plan item)
+
+1. **Propose** — what must change (policy, SDK gate, deletion path, label)
+2. **Risk** — what stays non-compliant or leaking if we skip it
+3. **Keep-working** — collection that is already disclosed and gated
+4. **Phase** — P0 / P1 / P2 (do not execute)
+
+## Worked example
+
+> **Propose:** delay PostHog init until consent; add account-deletion that
+> reaches Sentry + the analytics project.
+> **Risk:** GDPR consent-after-fire + incomplete erasure (PII in traces).
+> **Keep-working:** essential auth cookies already disclosed.
+> **Phase:** P0 — consent timing + deletion completeness.
+> **Execute-via:** `audit-analytics` (event gate) + `plan-error-handling` (logs).
+
+---
+
+## Phase 0 — Inventory personal data actually collected  [HIGH freedom]
+
+Do not trust the privacy policy. Derive collection from the code:
+
+- **Direct:** forms, signup, profile, uploads, voice/photo, location
+- **Automatic:** IP, device IDs, analytics, crash reports, cookies, session
+- **Special-category / 要配慮個人情報:** health, biometrics, precise location
+- **Third-party SDKs:** every analytics/ads/attribution/crash SDK and what it
+  exfiltrates by default
+
+Build: item → collected where → stored where → shared with → retention → basis.
+
+**Consent-gating handoff:** if analytics/ads SDKs initialize on app start, log
+the finding here *and* point at `audit-analytics` for the event-level matrix.
+
+---
+
+## Phase 1 — Audit against requirements  [HIGH freedom]
+
+**Collection vs claimed** — Diff inventory vs privacy policy vs App Store
+Nutrition Label / Play Data Safety. Collected-but-undisclosed is P0.
+
+**Consent** — Obtained *before* non-essential collection? Granular where GDPR
+requires? Withdraw path? APPI: 利用目的 specified and notified?
+
+**Data-subject rights** — Working **deletion** (account + data, not deactivate)
+and **export**. Must reach DB, buckets, logs, analytics, backups, third-party
+SDKs. A delete that leaves PII in Sentry is non-compliant.
+
+**Retention** — Defined windows + an enforcer (cron/TTL), or prose only?
+
+**Cross-border** — Processor region. EU→US needs a transfer basis. APPI
+restricts transfers outside Japan without consent/adequacy.
+
+**Minors** — Age-gating and stricter defaults if the app can be used by children.
+
+**Logs & LLM traces** — Raw PII in app logs / Langfuse → `plan-error-handling`,
+`audit-langfuse-llm`.
+
+---
+
+## Phase 2 — Phased plan (approve before executing)  [HIGH freedom — plan only]
+
+- **P0** — undisclosed collection, absent deletion, consent after fire, PII in logs
+- **P1** — incomplete deletion, missing export, no retention job, wrong store form
+- **P2** — consent granularity, policy wording, processor docs
+
+Each item: what's wrong, requirement (GDPR art. / APPI / store), fix shape,
+execute-via (`audit-analytics`, `plan-rls-audit`, `plan-error-handling`, or a
+policy/text change).
+
+## Self-critique before the burndown  [LOW freedom — do not skip]
+
+1. **From code, not the policy** — inventory derived from collection sites
+2. **Not legal advice** — ambiguity flagged for a lawyer
+3. **Collected-but-undisclosed is P0** — do not bury it in P2 wording
+4. **Right owner** — analytics fire-before-consent also → `audit-analytics`
+5. **Nothing rewritten** — no policy/SDK/deletion job until approved
+
+## Definition of Done
+
+- [ ] Inventory complete (collection → storage → sharing → retention)
+- [ ] Every third-party SDK's exfiltration documented
+- [ ] Real collection diffed against policy *and* store label
+- [ ] Consent timing + withdraw path checked; analytics handoff to `audit-analytics`
+- [ ] Deletion + export traced to all stores
+- [ ] Retention enforcement identified or flagged absent
+- [ ] Cross-border map per processor
+- [ ] Plan approved before any change
+
+## Output format
+
+1. **Data inventory** — item | where | stored | shared | retention | basis
+2. **Findings** — issue | GDPR/APPI/store | severity | evidence
+3. **Store-label diff** — claimed vs actual
+4. **Phased plan** — P0/P1/P2 → executing skill
+5. **Recap and await approval** — end the turn with a standalone recap in chat: the two or three highest-impact findings (collected-but-undisclosed first) and the first phase to approve. `plan-privacy-compliance.md` is the deliverable; write it before the recap.
+
+## Related
+
+- `audit-analytics` — event coverage + consent-gated firing (run both)
+- `plan-mobile-readiness` — store submission mechanics
+- `plan-rls-audit` — access control
+- `plan-error-handling` / `audit-langfuse-llm` — PII in logs/traces
+- `enhance-email-deliverability` — marketing-mail consent
+- `plan-aso` — listing copy after labels are honest

package/skills/plan-rls-audit/SKILL.md

@@ -0,0 +1,231 @@
+---
+name: plan-rls-audit
+description: >
+  Plan-only audit of Supabase/Postgres Row-Level Security and access-control
+  gaps. Use when "RLS", "is my Supabase secure", "anyone can read my data", or
+  "lock down my tables". App-layer route gates → audit-auth-flows.
+license: MIT
+effort: high
+---
+
+# RLS & Access-Control Audit + Remediation Plan
+
+**Degree of freedom: MIXED** — access matrix and severity are judgment; table
+inventory and policy reads run exactly. Stay **plan-only**. No SQL until approved.
+
+## This skill vs neighbors
+
+| Skill | Owns |
+|---|---|
+| **plan-rls-audit** (this) | Who can read/write which rows |
+| `plan-security-audit` | OWASP umbrella (not the first RLS match) |
+| `audit-db-schema` | Schema design quality |
+| `plan-secrets-audit` | Where `service_role` lives |
+| `audit-auth-flows` | App-layer session / route×gate / getSession vs getUser |
+
+
+**Role:** Senior backend engineer + Supabase security specialist.
+
+**Task:** Enumerate every table/view, run the RLS checklist (A–E), build a who-can-do-what
+access matrix, score findings by exposure, emit `plan-rls-audit.md`. **Audit & plan only —
+no SQL runs until each phase is approved.**
+
+## How to reason (every plan item)
+
+1. **Propose** — enable RLS, scope a policy, rotate a client `service_role`, or fix inverted logic
+2. **Risk** — anon/authed can read or write rows they should not
+3. **Keep-working** — tables whose policies already enforce ownership
+4. **Phase** — Stop exposure → Ownership → Correctness-perf → Adjacent gates (do not execute)
+
+## Worked example
+
+> **Propose:** enable RLS on `profiles`; replace `USING (true)` on `orders` SELECT with `user_id = (select auth.uid())`.
+> **Risk:** anon key (public) reads every profile; every authed user reads every order.
+> **Keep-working:** `orders` INSERT already checks owner.
+> **Phase:** Phase 1 — Stop active exposure (Critical).
+> **Direction:** policy shape only — no SQL in this pass. Client `service_role` → `plan-secrets-audit`.
+
+Missing or misconfigured Row-Level Security is the most documented vibe-coding
+catastrophe of the 2025–2026 era. An audit of 50 vibe-coded apps across Lovable,
+Bolt, v0, Cursor, and Claude Code found **88% had RLS entirely disabled** — not
+misconfigured, *disabled* — meaning the database returned any row to any query.
+Public breach reports describe apps leaking millions of API keys and user emails from
+exactly this, and a disclosed vulnerability class spanning many production apps where
+access control was present but **logically inverted** — authenticated users blocked,
+anonymous users granted everything.
+
+This skill is the **audit-and-plan** half of fixing that. Execution is handed to
+`backend-patterns` / `db-migrator` / `audit-security` after you approve each phase.
+
+---
+
+## When this fires
+
+Trigger phrases: *"check my RLS"*, *"is my Supabase locked down"*, *"can anyone
+read my tables"*, *"audit my database policies"*, *"service_role key"*,
+*"Supabase security advisor flagged something"*, *"pre-launch DB hardening"*.
+
+Do **not** fire for: pure query speed (`backend-db-performance`), schema/naming
+design (`audit-db-schema`), or broad app-layer OWASP (`plan-security-audit`).
+RLS is specifically *who can read/write which rows*, enforced at the database.
+
+---
+
+## Why a dedicated skill (not generic security audit)
+
+RLS failure is *mechanical and table-by-table*. A generic OWASP sweep glances at
+it; this enumerates every table and applies a deterministic checklist. Fixing RLS
+is the first step when the anon key can read rows it should not.
+
+---
+
+## The audit checklist  [HIGH freedom]
+
+Walk the schema (via Supabase MCP, `pg_tables`, migration files, or the dashboard
+security advisor). For **every** table and view:
+
+### A · Is RLS even on?
+- Check `relrowsecurity = true` for every table in exposed schemas (`public`
+  especially). Any table with RLS **off** is fully readable/writable through the
+  anon key. This is finding #1, severity Critical, every time it appears.
+- Views: confirm they don't silently bypass RLS (`security_invoker` vs definer).
+- Don't forget junction/lookup tables — they leak relationships even when the
+  "main" tables are protected.
+
+### B · Are the policies real, or theater?
+- **`USING (true)`** (or `WITH CHECK (true)`) on anything user-owned = the table
+  is public. The agent writes this to make a "permission denied" error go away;
+  it's the single most common dangerous pattern.
+- **Inverted logic** (the disclosed inverted-policy class): a policy that *looks* like it
+  checks auth but blocks the wrong party. Read each policy's truth table, don't
+  trust its name.
+- **Missing operation coverage**: a SELECT policy with no INSERT/UPDATE/DELETE
+  policy (or vice-versa) — RLS denies by default *only* if RLS is on, so confirm
+  each operation the app performs is actually governed.
+- **Ownership not enforced**: policy references `auth.uid()` but doesn't tie it to
+  a row-owner column (`user_id = auth.uid()`), so any logged-in user reads every
+  other user's rows.
+
+### C · Key scoping (the client-side trap)
+- Search frontend/client bundles for the **`service_role`** key. It bypasses RLS
+  entirely and must never be shipped client-side or in `NEXT_PUBLIC_*`. If found:
+  Critical, rotate immediately (hand to `plan-secrets-audit`).
+- Confirm the **anon** key is the only Supabase key in client code, and that
+  anon access is safe *because RLS holds* — not by accident.
+- Edge Functions / server routes using `service_role`: verify they re-check
+  authorization in code, since they've opted out of RLS.
+
+### D · Correctness & performance of auth calls
+- Supabase's own linter flags `auth.uid()` called per-row. Recommend
+  `(select auth.uid())` so Postgres caches it — correctness is unchanged but
+  large tables stop timing out (a real fix, not cosmetic).
+- Check `auth.jwt()` / custom claims usage for the same per-row trap.
+
+### E · Defaults & adjacent gates
+- Storage buckets: public vs RLS-governed; signed-URL usage.
+- Realtime: row-level authorization on subscribed channels.
+- `pg_policies` cross-checked against the app's actual access matrix — flag any
+  table the app reads/writes that has *no* corresponding policy.
+
+For each finding: table/policy, the exact gap, who can currently access what,
+severity, and a remediation *direction* (not the SQL — that's execution).
+
+---
+
+## Procedure  [HIGH freedom — plan only]
+
+1. **Inventory.**  [LOW freedom — run exactly] List every table/view in exposed schemas with its
+   `relrowsecurity` state and policy set. State how you accessed it (MCP /
+   migrations / advisor) and any tables you couldn't see.
+2. **Classify.** Run each through checklist A–E. Tag severity:
+   **Critical** (RLS off, `USING(true)`, service_role client-side, inverted
+   policy), **High** (ownership not enforced, missing operation coverage),
+   **Med** (perf-trap auth calls, view bypass), **Low** (hardening nits).
+3. **Build the access matrix.** A who-can-do-what table the user can eyeball —
+   the deliverable's most useful artifact.
+4. **Phase the burndown.** Critical first (data is exposed *right now*), then
+   High, then Med/Low. Each phase maps to an execution skill.
+5. **Emit `plan-rls-audit.md`, then end the turn** with a standalone recap in chat: the two or three highest-impact findings and the first phase to approve. The file is the deliverable — write it before the recap. **Do not write or run any SQL.**
+
+---
+
+## Guardrails
+
+- **Plan only.** No `ALTER TABLE`, no `CREATE POLICY`, no migrations. The
+  deliverable is the report and the access matrix.
+- **Never widen access to "verify".** Don't suggest temporarily disabling RLS or
+  loosening a policy to test something. Read state; don't mutate it.
+- **Assume the anon key is public.** It is — it ships in the browser. The plan's
+  job is to confirm RLS makes that safe, not to treat the key as a secret.
+- **Severity is about exposure, not effort.** An RLS-off table is Critical even
+  if the fix is one line. Rank by what's reachable today.
+- **Don't confuse "works in the demo" with "secure".** App-layer filtering
+  (`.eq('user_id', currentUser)` in the client query) is *not* RLS; flag it as
+  unprotected — anyone can drop the filter in dev tools.
+- **Minimal quoting** of policy bodies; identify by table + operation.
+
+## Self-critique before the burndown  [LOW freedom — do not skip]
+
+1. **evidenced-not-assumed** — every table has `relrowsecurity` + policy set from MCP/migrations/advisor; unseen tables listed
+2. **plan-only** — no `ALTER TABLE`, no `CREATE POLICY`, no widening access to "verify"
+3. **severity/phase justified** — RLS-off / `USING (true)` / inverted / client `service_role` = Critical even if the fix is one line
+4. **right-owner** — rotate exposed `service_role` → `plan-secrets-audit`; app-layer session/route gates → `audit-auth-flows`; schema design → `audit-db-schema`
+5. **no-false-safety** — client `.eq('user_id', …)` is not RLS; anon key is public; "works in the demo" is not secure
+
+---
+
+## Report template — `plan-rls-audit.md`
+
+```markdown
+# RLS & Access-Control Audit — <project>
+
+_Audit-only. No SQL runs until each phase is approved._
+
+## Scope
+- Tables/views audited: n  | Source: [Supabase MCP / migrations / advisor]
+- Couldn't inspect: …  | Assumptions: …
+
+## Verdict
+| Severity | Count | Worst case if shipped |
+|----------|-------|-----------------------|
+| Critical | n     | full DB readable via anon key |
+| High     | n     | cross-user data access |
+| Medium   | n     | timeouts / view bypass |
+| Low      | n     | hardening |
+
+## Access matrix (current reality)
+| Table | RLS on? | anon can | authed (own) | authed (others') | service_role exposed? |
+|-------|---------|----------|--------------|------------------|-----------------------|
+| profiles | ❌ | read+write all | — | YES ⚠ | — |
+
+## Findings
+| # | Table / policy | Gap | Who's exposed | Sev | Direction |
+|---|----------------|-----|---------------|-----|-----------|
+| R1 | profiles | RLS disabled | everyone, anon | Crit | enable RLS; add owner policy |
+| R2 | orders | USING (true) on SELECT | every authed user reads all orders | Crit | scope to user_id = (select auth.uid()) |
+
+## Phased burndown
+- **Phase 1 — Stop active exposure** → `db-migrator` / `backend-patterns` — R1, R2…
+- **Phase 2 — Enforce ownership** → `db-migrator` — H-tier items
+- **Phase 3 — Correctness & perf** → `backend-db-performance` — auth.uid() traps
+- **Phase 4 — Adjacent gates** → `audit-security` — storage, realtime
+
+## Execution handoff
+Approve a phase to run it. Re-run `plan-rls-audit` after to confirm closure, and
+cross-check with Supabase's security advisor.
+```
+
+---
+
+## Chains with
+
+- **Security spine** — entry: `plan-input-validation`; credentials:
+  `plan-secrets-audit`; data access: **this skill**; blast radius:
+  `plan-data-integrity`; observability: `plan-error-handling`.
+- **`plan-secrets-audit`** — any exposed `service_role` key found here hands
+  straight over (rotation, not relocation).
+- **Execution:** `db-migrator`, `backend-patterns`, `backend-db-performance`,
+  `audit-security`.
+- **Verify:** Supabase security advisor + a second `plan-rls-audit` pass.
+
+> Planned at high effort; executed at the default effort under the approved-plan execution rule (`approved-plan-execution.mdc`), which forbids reward hacking and feature deletion on any model. The plan says *which* tables are exposed; the rule constrains *how* the migration is allowed to touch them.

package/skills/plan-secrets-audit/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: plan-secrets-audit
+description: >
+  Plan-only scan of the working tree and git history for exposed or mis-scoped
+  keys, then a rotate-vs-relocate plan. Use when "hardcoded secrets", "did I
+  commit a key", "secret scan", "is my .env safe", or "rotate keys".
+license: MIT
+effort: high
+---
+
+# Secrets & Key-Scope Audit + Rotation Plan
+
+**Degree of freedom: MIXED** — prefix scan is exact; rotate-vs-relocate
+is judgment. Stay **plan-only**. Never print secret values.
+
+## This skill vs neighbors
+
+| Skill | Owns |
+|---|---|
+| **plan-secrets-audit** (this) | Rotate vs relocate leaked keys |
+| `plan-security-audit` | OWASP umbrella (not the first secrets match) |
+| `plan-rls-audit` | Table access control |
+| `audit-env-parity` | Env/config drift |
+
+## How to reason (every plan item)
+
+1. **Propose** — rotate, relocate, or hygiene — say which, never print the value
+2. **Risk** — who can use the key if it stays live (history counts)
+3. **Keep-working** — keys that are scoped correctly and not in history
+4. **Phase** — rotate → relocate → hygiene → optional scrub (do not execute)
+
+## Worked example
+
+> **Propose:** rotate the Stripe secret at `api/pay.ts` (last-4 only in the report); history presence means rotate, not `.env` move.
+> **Risk:** `sk_` in committed history stays valid forever after a relocate.
+> **Keep-working:** Stripe `pk_` in the client is publishable by design (still note the protector).
+> **Phase:** Phase 1 — rotate exposed never-client secrets.
+> **Redaction:** type + path + last 4 — never the secret.
+
+**Role:** Senior security engineer (credential exposure + key scoping).
+
+**Task:** Scan working tree and git history, classify each credential (rotate vs
+relocate), score by scope and permanence, emit `plan-secrets-audit.md`. **Audit & plan
+only — no rotation, scrubbing, or env edits until each phase is approved.**
+
+**Find every leaked key. Decide rotate vs relocate. Change nothing until approved.**
+
+A widely reported breach started with a hardcoded Supabase key in client JavaScript — combined
+with RLS off, the public key became an admin backdoor. **A secret committed even once
+lives in git history forever.** Moving it to `.env` later does nothing; the only real
+fix is **rotation**.
+
+---
+
+## When this fires
+
+Trigger phrases: *"scan for secrets"*, *"are my keys exposed"*, *"did I commit an
+API key"*, *"is my .env safe"*, *"rotate keys"*, *"about to open-source this"*,
+*"pre-launch secret check"*.
+
+Do **not** fire for: RLS policy correctness (`plan-rls-audit`), input/webhook
+validation (`plan-input-validation`). This skill owns *credential exposure and
+key scoping* specifically.
+
+---
+
+## Why a dedicated skill
+
+A grep finds strings. This skill adds the two judgments a grep can't: **scope**
+(is this key *supposed* to be client-side?) and **permanence** (is it in history,
+making relocation insufficient?).
+
+---
+
+## The audit
+
+### A · Pattern scan (working tree)  [LOW freedom — run exactly]
+Search outside `.env*` and server-only contexts for:
+- Prefixes: `sk_`, `pk_`, `whsec_`, `service_role`, `eyJ...`, `AKIA`, `API_KEY`,
+  `SECRET`, `TOKEN`, long random blobs.
+- Supabase: anon vs `service_role`.
+- Any key in files that ship to the browser.
+
+### B · Scope classification  [HIGH freedom]
+- **Safe client-side:** Supabase **anon**, Stripe **publishable** (`pk_`), public
+  analytics keys — note the protector dependency (RLS, Stripe design).
+- **Never client-side (Critical if exposed):** **service_role**, Stripe **secret**
+  (`sk_`), **webhook secret** (`whsec_`), AWS secrets, DB URLs.
+- **`NEXT_PUBLIC_` / `VITE_` / `EXPO_PUBLIC_` trap** — bundled into client.
+
+### C · Git history (rotate vs relocate)  [HIGH freedom]
+- Ever in committed history → **rotate** (relocation is theater).
+- Scrubbing (filter-repo/BFG) is secondary — rotation first.
+
+### D · Deployment env config (Vercel / AWS)  [HIGH freedom]
+- Secrets in platform env store, not baked into build.
+- `.env.example` not committed with real values.
+- No secrets as build args (persist in image layers).
+
+### E · `.gitignore` & hygiene  [HIGH freedom]
+- `.env*` ignored; no secrets in README, comments, test fixtures.
+
+---
+
+## Procedure  [HIGH freedom]
+
+1. **Scan** working tree (A), classify scope (B).
+2. **Check history** for every credential (C).
+3. **Review deploy + hygiene** (D, E).
+4. **Score.** Never-client in client bundle or history = Critical.
+5. **Phase.** **Emit `plan-secrets-audit.md`, then end the turn** with a standalone recap in chat: the two or three highest-impact findings (type + location + last 4, never the value) and the first phase to approve. The file is the deliverable — write it before the recap.
+
+---
+
+## Guardrails  [LOW freedom — run exactly]
+
+- **Plan only.** No rotation, history rewriting, or env edits.
+- **Never print the secret.** Type + location + last 4 chars at most.
+- **Rotate beats relocate — always say which.**
+- **Don't assume safe-client keys are fine.** Hand anon-key + no-RLS to
+  `plan-rls-audit`.
+- **Order:** rotate → update env store → redeploy → (optional) scrub history.
+
+## Self-critique before the burndown  [LOW freedom — do not skip]
+
+1. **evidenced-not-assumed** — type + location + last 4; never the secret value
+2. **plan-only** — no rotation, scrub, or env edit this pass
+3. **phase justified** — history → rotate is Phase 1, not "move to `.env`"
+4. **right-owner** — anon-key + no-RLS → `plan-rls-audit`; generic OWASP → `plan-security-audit`
+5. **no-false-safety** — relocate-without-rotate is theater; safe-client still needs its protector
+
+---
+
+## Report template — `plan-secrets-audit.md`
+
+```markdown
+# Secrets & Key-Scope Audit — <repo>
+
+_Audit-only. No key is rotated, moved, or scrubbed until each phase is approved._
+
+## Scope
+- Scanned: working tree ☐  git history ☐  deploy env (Vercel/AWS) ☐
+- Assumptions / not inspected: …
+
+## Verdict
+| Severity | Count | Worst case |
+|----------|-------|-----------|
+| Critical | n | never-client secret exposed / in history |
+| High     | n | committed .env values, public-prefix leak |
+| Medium   | n | shared-env keys, hygiene |
+
+## Findings
+| # | Key type | Location | Scope bucket | In history? | Action | Sev |
+|---|----------|----------|--------------|-------------|--------|-----|
+| S1 | Supabase service_role | lib/admin.ts:4 | never-client | YES | ROTATE now | Crit |
+| S2 | Stripe secret sk_ | api/pay.ts:2 | never-client | YES | ROTATE now | Crit |
+| S3 | Supabase anon | client.ts:6 | safe-client | n/a | OK if RLS holds → plan-rls-audit | — |
+| S4 | DB URL | .env.example | never-client | YES | ROTATE + remove from example | High |
+
+## Phased burndown
+- **Phase 1 — Rotate exposed never-client secrets** → dashboard rotation + Vercel/AWS env update (grace window)
+- **Phase 2 — Relocate clean secrets** → move to env store, fix NEXT_PUBLIC_ leaks
+- **Phase 3 — Hygiene** → .gitignore, remove committed examples, CI secret scanner
+- **Phase 4 — (optional) Scrub history** → filter-repo/BFG, after rotation
+
+## Execution handoff
+Approve a phase to run it. Cross-hand safe-client keys to `plan-rls-audit`.
+Add a pre-commit secret scanner (`create-hook`) so this can't regress.
+```
+
+---
+
+## Chains with
+
+- **Security spine** — credentials layer (**this skill**); cross-hand to
+  `plan-rls-audit` for anon-key safety.
+- **`create-hook`** — pre-commit secret-scanning hook as regression guard.
+- **Execution:** provider dashboards, Vercel/AWS env, `audit-security`.
+- **Verify:** re-scan working tree + history; confirm rotated keys are dead.
+
+> Planned at high effort; executed at the default effort under the approved-plan execution rule (`approved-plan-execution.mdc`), which forbids reward hacking and feature deletion on any model. Rotation is irreversible-ish — the plan says *which* keys; the rule constrains *how* and *in what order*.