What problem does it solve?
Supabase projects often end up with scattered client setup, unsafe direct queries, missing Row Level Security (RLS) policies, and brittle real-time subscriptions that leak connections, making refactors risky and data access unpredictable.
Core Features & Use Cases
- Separation of server and browser clients: Use @supabase/ssr to create a server client that reads session cookies and a browser client for client components, avoiding session errors.
- Repository-based data access layer: Route all supabase.from() queries through src/repositories files so services and UI never call Supabase directly.
- RLS-first security model: Enable RLS on every table and define policies tied to auth.uid() for isolation.
- Safe Realtime subscriptions: Subscribe in Client Components and always unsubscribe in useEffect cleanup to prevent WebSocket leaks.
- Use Case: You’re onboarding an AI coding agent to refactor a Next.js app that uses Supabase; this skill enforces consistent client setup, typed repositories, RLS policies, and correct realtime lifecycle.
Quick Start
Run the Supabase skill to restructure your project so server/browser clients are separated, repositories own all queries, RLS policies cover every table, and realtime subscriptions are cleaned up correctly.