supabase-rls-policy-generator
This skill should be used when the user requests to generate, create, or add Row-Level Security (RLS) policies for Supabase databases in multi-tenant or role-based applications. It generates comprehensive RLS policies using auth.uid(), auth.jwt() claims, and role-based access patterns. Trigger terms include RLS, row level security, supabase security, generate policies, auth policies, multi-tenant security, role-based access, database security policies, supabase permissions, tenant isolation.
View on GitHubTable of content
This skill should be used when the user requests to generate, create, or add Row-Level Security (RLS) policies for Supabase databases in multi-tenant or role-based applications. It generates comprehensive RLS policies using auth.uid(), auth.jwt() claims, and role-based access patterns. Trigger terms include RLS, row level security, supabase security, generate policies, auth policies, multi-tenant security, role-based access, database security policies, supabase permissions, tenant isolation.
Installation
npx claude-plugins install @hopeoverture/worldbuilding-app-skills/supabase-rls-policy-generator
Contents
Folders: skills
Included Skills
This plugin includes 1 skill definition:
supabase-rls-policy-generator
This skill should be used when the user requests to generate, create, or add Row-Level Security (RLS) policies for Supabase databases in multi-tenant or role-based applications. It generates comprehensive RLS policies using auth.uid(), auth.jwt() claims, and role-based access patterns. Trigger terms include RLS, row level security, supabase security, generate policies, auth policies, multi-tenant security, role-based access, database security policies, supabase permissions, tenant isolation.
View skill definition
Supabase RLS Policy Generator
To generate comprehensive Row-Level Security policies for Supabase databases, follow these steps systematically.
Step 1: Analyze Current Schema
Before generating policies:
- Ask user for the database schema file path or table names
- Read the schema to understand table structures, foreign keys, and relationships
- Identify tables that need RLS protection
- Determine the security model: multi-tenant, role-based, or hybrid
Step 2: Identify Security Requirements
Determine access patterns by asking:
- Is this a multi-tenant application? (tenant_id isolation)
- What roles exist in the system? (admin, user, viewer, etc.)
- Are there public vs private resources?
- Do users need to share resources across accounts?
- Are there hierarchical permissions? (organization > team > user)
Consult references/rls-patterns.md for common security patterns.
Step 3: Generate RLS Policies
For each table requiring protection, generate policies following this structure:
Enable RLS
ALTER TABLE table_name ENABLE ROW LEVEL SECURITY;
Policy Types to Generate
SELECT Policies - Control read access:
- User can view their own records
- User can view records in their tenant
- Role-based viewing (admins see all)
- Public records accessible to all authenticated users
INSERT Policies - Control creation:
- User can create records with their own user_id
- User can create records in their tenant
- Role-based creation restrictions
…(truncated)