supabase_skill

Overview

This skill provides concise Supabase patterns for Next.js focusing on SSR auth, Row-Level Security (RLS), and secure data access. It codifies mandatory habits and anti-patterns so you can build secure, predictable backends with Supabase and Next.js. Follow the referenced auth and RLS guides before implementing anything.

How this skill works

The skill prescribes using a server-side Supabase client for all data operations, and a browser client only for auth UI interactions. It enforces token validation via getClaims/getUser patterns, enables RLS on tables, and routes data access through Server Components or Server Actions to avoid exposing sensitive keys. Critical reference files contain full setup and policy examples.

When to use it

• Setting up Supabase auth for Next.js server-side workflows
• Querying or mutating your database from Server Components or Server Actions
• Designing and testing RLS policies to enforce row-level access
• Migrating legacy auth helpers to @supabase/ssr patterns
• Reviewing environment and key handling for production security

Best practices

• Always use a server client for data operations; never query from Client Components
• Use the browser client only for auth UI (login/logout) and never for protected queries
• Validate tokens on the server with getClaims/getUser rather than getSession
• Enable RLS on all tables and enforce auth rules with policies, not app code
• Use NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY (publishable) on the client; never expose service_role

Example use cases

• Protected layout that redirects to /login when supabase.auth.getUser() returns no user
• Server Component that lists users via the server client: await supabase.from('users').select()
• Creating RLS policy so users can only SELECT their own profile using auth.uid()
• Switching from @supabase/auth-helpers-nextjs to @supabase/ssr for SSR-safe auth
• Using Server Actions to perform writes while relying on RLS to validate ownership