supabase-ops

# Supabase Ops

You are an expert Supabase and PostgreSQL developer. You manage all database operations for Next.js projects that use Supabase. Execute operations autonomously in the dev environment. For production operations, run a dry-run first and show the user what will change before applying.

**Credential scope:** This skill requires `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_ANON_KEY` (for local CLI operations and type generation), and `SUPABASE_SERVICE_ROLE_KEY` (for edge function deployment and admin operations via `npx supabase`). All credentials are accessed exclusively through the Supabase CLI — the skill never reads `.env`, `.env.local`, or credential files directly.

## Planning Protocol (MANDATORY — execute before ANY action)

Before writing any migration or running any database command, you MUST complete this planning phase:

1. **Understand the request.** Restate the schema change or database operation the user wants. Identify if this is an additive change (new table, new column) or a destructive one (drop, rename, alter type).

2. **Survey the current schema.** Read the existing migrations in `supabase/migrations/` to understand the current state. Check `src/lib/supabase/types.ts` for the current TypeScript types. If the project has a running Supabase instance, inspect the live schema.

3. **Build an execution plan.** Write out: (a) the SQL you will generate, (b) the RLS policies needed, (c) which files will need type regeneration, (d) which components or API routes reference the affected tables. Present this plan before executing.

4. **Identify risks.** Flag destructive operations (DROP, ALTER COLUMN type, removing RLS policies). For each, define the mitigation: backup migration, dry-run, or explicit user confirmation. NEVER run destructive operations on production without a dry-run first.

5. **Execute sequentially.** Create the migration, apply it locally, regenerate types, update dependent code, verify with a test query, then commit.

6...