iconsa-rls-validation

Validates PostgreSQL Row Level Security policies across HumanOS Supabase schemas.

Updated May 7, 2026
One-click install
npx skills add https://github.com/jecg2804/HumanOS --skill iconsa-rls-validation-jecg2804
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: iconsa-rls-validation
Source: https://github.com/jecg2804/HumanOS/tree/main/.claude/skills/iconsa-rls-validation
Command: npx skills add https://github.com/jecg2804/HumanOS --skill iconsa-rls-validation-jecg2804

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After any database migration or schema change, it is easy to leave tables without Row Level Security enabled or with missing policies, creating silent security gaps where sensitive HR data (medical info, salaries, personal documents) could be exposed or where the app silently fails to read data. This Skill runs a structured verification suite against pg_policies and pg_class to catch those gaps immediately. ## Core Features & Use Cases - Coverage Verification: Detects tables without RLS enabled and tables with RLS enabled but zero policies across the hr, requests, docs, workflows, audit, notifications, files, performance, and learning schemas. - Sensitive Table Auditing: Verifies that medical_info, personal_documents, and salary-related policies follow the ownership-or-HR-admin pattern required by rule R13. - Functional Impersonation Tests: Simulates an authenticated user via JWT claims to confirm one employee cannot read another employee's protected rows. - Use Case: After creating a new table in the requests schema, run the verification queries to confirm RLS is enabled, policies exist for SELECT/INSERT/UPDATE, and WITH CHECK clauses validate written rows. ## Quick Start Validate the RLS policies on the new table I just created in the hr schema and tell me if anything is missing.

Frequently Asked Questions about iconsa-rls-validation

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

FAQPage Schema
How do I check if RLS is enabled on all PostgreSQL tables?▼

Query pg_class joined with pg_namespace filtering on relrowsecurity = false for your schemas. Any returned rows are unprotected tables that need ALTER TABLE ... ENABLE ROW LEVEL SECURITY immediately.

How to find tables with RLS enabled but no policies?▼

Left join pg_class with pg_policies and group by table, filtering where the policy count is zero. These tables deny all access by default, so the application will silently fail to read or write data.

Why does my Supabase app return no rows after enabling RLS?▼

Enabling RLS without creating any policies blocks all access, including legitimate reads. Create at least a SELECT policy with an ownership predicate such as person_id matching the current user, plus INSERT and UPDATE policies with WITH CHECK.

Should I use auth.uid() directly in Supabase RLS policies?▼

Prefer a helper function like hr.current_person_id() instead of calling auth.uid() directly in every policy. Helpers keep policies consistent, and they should be declared SECURITY DEFINER with an empty search_path.

How do I test RLS policies by impersonating a user in PostgreSQL?▼

Use SET LOCAL ROLE authenticated and set request.jwt.claims to the target user's auth ID, then run a SELECT against protected data. If a non-admin user can read another person's rows, the policy predicate is wrong.

When should USING (true) be avoided in RLS policies?▼

Avoid USING (true) unless justified in a comment, because it grants access to every row. Use ownership predicates instead, and always add WITH CHECK on INSERT and UPDATE policies to validate written rows.