Supabase

Build a migration-backed, typed Supabase integration with explicit authorization boundaries.

Workflow

1. Inspect supabase/, migrations, generated types, installed Supabase packages/versions, framework/runtime, environment-variable names without printing values, auth/session flow, schemas exposed through the Data API, and existing grants/RLS.
2. Infer table ownership and tenant relationships from the domain model. Ask only when ownership, collaboration, deletion, retention, or external-auth behavior is ambiguous. Do not add user_id or four CRUD policies to every table mechanically.
3. Design keys, foreign keys, constraints, indexes, timestamps, lifecycle/deletion behavior, and server-generated ownership defaults appropriate to each table. Use external provider subject IDs as text unless a local identity mapping is intentionally modeled.
4. Create named migrations. Use supabase migration new or a reviewed db diff for local changes, verify with a local reset/test database, inspect db push --dry-run, and use db push only when remote deployment is explicitly in scope. migration up is not a substitute for remote deployment.
5. Secure every exposed object with both Postgres grants and RLS. Scope policies to roles, use indexed predicates, add with check for inserts/updates, review views/functions separately, and set a safe search_path on security definer functions.
6. Match auth strategy:
   • Supabase Auth: use auth.uid()/auth.jwt() and current SSR session guidance.
   • Clerk or another supported third-party provider: configure the native integration, pass the provider token through the client, and use the actual JWT sub/claims. Do not assume an RLS expression alone configures token verification.
   • Server administration: use a dedicated server-only client with explicit authorization; never expose secret/service credentials.
7. For current @supabase/ssr, create a client per request, use the supported cookie getAll/setAll adapter, await async framework cookie APIs, and add the required proxy/middleware refresh flow. Do not use legacy single-cookie adapters.
8. Generate TypeScript types after applying migrations to the target used for generation, then run type checks and update typed queries. Avoid any and handle { data, error } explicitly.

Verification

Run local migration reset/apply, schema/type drift checks, and repository lint/type/test/build. For each policy, test allowed owner/member/admin/service access and denied anonymous/other-user/other-tenant reads and mutations, including attempts to change ownership. Test session refresh/expiry and external-provider tokens in the target runtime.

Output

Report tables/functions/storage changed, migration files, grants and RLS policies with auth strategy, client/session changes, type-generation command/result, negative authorization tests, and remaining linked-project/dashboard/production steps.