db-policy-apply

Installs KISS or granular row-level security policies on Supabase PostgreSQL tables.

3|Updated Feb 7, 2026
One-click install
npx skills add https://github.com/gabrielnsmnto/kord-aios --skill db-policy-apply-gabrielnsmnto
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: db-policy-apply
Source: https://github.com/gabrielnsmnto/kord-aios/tree/main/src/features/builtin-skills/kord-aios/database/db-policy-apply
Command: npx skills add https://github.com/gabrielnsmnto/kord-aios --skill db-policy-apply-gabrielnsmnto

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Manually writing and applying Row Level Security (RLS) policies in Supabase is error-prone and often leads to performance issues or security gaps, such as unindexed filter columns or unsafe use of user-modifiable metadata. This Skill standardizes the creation, migration, and testing of RLS policies on database tables. ## Core Features & Use Cases - Policy Templates: Applies either a single KISS policy covering all operations or granular per-operation policies (SELECT, INSERT, UPDATE, DELETE) with performance-optimized cached auth.uid() calls. - Migration Generation: Creates timestamped SQL migration files, applies them, and verifies the policies with role-based tests. - Security Guardrails: Warns against dangerous patterns like using raw_user_meta_data in policies and enforces NULL checks for unauthenticated users. - Use Case: After creating a new 'projects' table in Supabase, apply a KISS RLS policy so each authenticated user can only read and modify their own rows, with the migration committed to version control. ## Quick Start Apply a KISS row-level security policy to the projects table in my Supabase database and generate the migration file.

Frequently Asked Questions about db-policy-apply

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I apply RLS policies to a Supabase table?▼

Provide the table name and choose a mode: 'kiss' creates one policy covering all operations, while 'granular' creates separate SELECT, INSERT, UPDATE, and DELETE policies. The skill validates the table exists, generates a migration file, applies it, and tests the policies.

What is the difference between KISS and granular RLS policies?▼

KISS uses a single policy for all operations, making it simpler to understand and maintain. Granular creates separate policies per operation, giving fine-grained control and allowing different logic per operation at the cost of more verbose SQL.

Why wrap auth.uid() in a SELECT inside RLS policies?▼

Wrapping auth.uid() in a SELECT, as in (select auth.uid()), lets PostgreSQL cache the function result per statement instead of re-evaluating it per row. This provides a dramatic performance improvement on large tables.

Is it safe to use raw_user_meta_data in RLS policies?▼

No. Users can modify their own user_metadata through the Supabase Auth client, so an attacker could set an admin role and bypass security. Use raw_app_meta_data instead, which only the server can modify.

What prerequisites does a table need before applying RLS policies?▼

The table needs a user_id UUID column for user-based policies or a tenant_id column for tenant-based policies. Indexes on all policy filter columns are critical for performance, such as an index on user_id.