supabase-as-a-service: Skill for Claude Code

Port a feature from this app into the vibe-starter template

The goal each time: take one feature out of this production app and drop it into the supabase-vibe-starter template as a new .Codex/skills/<feature>/ skill the template's AI can build out per-project. You are handing over concept + security model + adapted build-spec + verbatim source — not wiring it live into the app (unless the user asks). The template stays clean; nothing here is committed unless the user says so.

The target

• Path: /Users/alfrednutile/Apps/Videos/supabse-vibecoding-starter (note the typo'd supabse — that is the real folder name).
• What it is: a deliberately minimal React + Vite + TS + Supabase starter — a "stack smoke-test" (auth + documents table + RLS + realtime + private Storage).
• What it does NOT have (so you must adapt, not copy): no react-router, no tailwind (plain CSS in src/index.css), no AuthContext (App switches on session), no admin/roles, no Vault, no activity_log, no edge functions yet.
• Read references/target-conventions.md for the exact conventions + the source→target adaptation map before writing any code.

The method (what worked, do it again)

1. Map the feature's full surface in THIS repo. A feature is rarely one file. Grep for it and enumerate: the UI page(s) (src/pages/*), pure logic + tests (src/lib/*.ts + *.test.ts), the edge function(s) (supabase/functions/*), migration(s) (supabase/migrations/*), any GitHub workflow, and the wiring (supabase/config.toml, src/App.tsx route, src/lib/nav.ts). The feature is often documented in AGENTS.md — read that section first.

2. Capture the concept + the security model. The most valuable part to hand over is why it's built this way — the trust boundary, what's owner-only vs workspace vs admin, what's attacker-reachable, what fails open vs closed. Write this as prose, not code.

3. List the dependencies and how they map. For each thing the feature leans on (Vault, profiles.is_admin, activity_log, a storage bucket, realtime, a model profile, another builtin), decide: reuse an equivalent in the target, substitute a minimal version, or drop it as optional. Record every decision in ORIGIN.md.