g14wxz/tenant-isolation-rls
Enforces absolute data boundaries between tenants in shared schema via RLS policies on tenant_id.
100
100%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly articulates specific capabilities (RLS policy creation, tenant_id isolation verification), prerequisites (tenant_id column, JWT claims), and explicit trigger conditions. It uses third-person voice consistently and provides enough technical specificity to be both discoverable and distinguishable from other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: creates RLS policies enforcing tenant_id isolation, verifies ALTER TABLE ENABLE ROW LEVEL SECURITY before policy creation, requires tenant_id column and custom-access-token-hook JWT claims. | 3 / 3 |
Completeness | Clearly answers both what (creates RLS policies enforcing tenant_id isolation, verifies ALTER TABLE ENABLE ROW LEVEL SECURITY) and when (explicit 'Use when' clause with four trigger scenarios: multi-tenant data isolation, tenant-safe queries, shared schema RLS, tenant_id policy creation). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'multi-tenant', 'data isolation', 'tenant_id', 'RLS', 'shared schema', 'row level security', 'policy creation', 'tenant-safe queries'. Good coverage of domain-specific terms. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche combining multi-tenant architecture, RLS policies, tenant_id isolation, and JWT claims. Very unlikely to conflict with other skills due to the specific combination of Supabase/PostgreSQL RLS and multi-tenancy concepts. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
100%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is an excellent, tightly-written skill that provides concrete SQL, explicit verification queries, and clear halt conditions at every critical juncture. It assumes Claude's competence with Supabase and PostgreSQL concepts while adding only the domain-specific workflow and constraints Claude wouldn't otherwise know. The phased structure with validation checkpoints is exemplary for a destructive/security-critical operation.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line serves a purpose—no explanation of what RLS is, what JWTs are, or how Supabase works. Pre-conditions are stated as terse requirements, and phases contain only the necessary steps and SQL. | 3 / 3 |
Actionability | Provides executable SQL for the SELECT policy, specific system catalog queries for verification (pg_class.relrowsecurity, pg_policies), and concrete column/claim paths (auth.jwt() -> 'app_metadata' ->> 'tenant_id'). The INSERT/UPDATE/DELETE policies are described by analogy to the fully-specified SELECT policy, which is sufficient. | 3 / 3 |
Workflow Clarity | Five clearly sequenced phases with explicit HALT checkpoints after verification failures (missing column, RLS not enabled, conflicting anon policy, verification report failures). Each phase has a validation step and a clear error-recovery posture (halt and report). | 3 / 3 |
Progressive Disclosure | The skill is under 50 lines, single-purpose, and well-organized into labeled phases with clear section headers. No external references are needed, and the structure supports easy scanning. | 3 / 3 |
Total | 12 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents