CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/row-level-security-postgres-reference

Pure-reference catalog of Postgres Row-Level Security (RLS) for tenant isolation. Covers enabling RLS (ALTER TABLE ... ENABLE ROW LEVEL SECURITY, default-deny semantics), CREATE POLICY syntax (USING vs WITH CHECK clauses, FOR SELECT/INSERT/UPDATE/DELETE/ALL, permissive vs restrictive, TO role_name), bypassing RLS (superuser / BYPASSRLS / table owner / FORCE ROW LEVEL SECURITY), tenant context patterns (current_user, current_setting, JWT claims via Supabase auth.uid() / auth.jwt()), performance discipline (wrapping auth functions in SELECT, index on policy-referenced columns), and anti-patterns. Use as the RLS-pattern reference for Postgres-backed tenant isolation. Consumed by tenant-leak-test-author, cross-tenant-data-leak-tests.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable RLS reference with clear multi-step workflow, explicit validation checkpoints, and clean one-level-deep file splitting. The only weakness is mild verbosity in the Overview where it restates Postgres documentation and contrasts GRANT/REVOKE concepts Claude already knows.

Suggestions

Trim the Overview prose: drop the GRANT/REVOKE contrast and the inline Postgres-doc paraphrases (e.g. 'restricts which rows users can access', 'Once enabled, a default-deny policy applies ...') - keep the default-deny fact in the Enabling RLS section only.

Remove doc-quote restatements that duplicate the linked references; let the canonical references carry the prose and keep SKILL.md to commands, tables, and triggers.

DimensionReasoningScore

Conciseness

The body is mostly efficient - dense anti-pattern and performance tables plus executable SQL - but the Overview re-explains the GRANT/REVOKE contrast and paraphrases Postgres docs ('restricts which rows users can access ...', 'Once enabled, a default-deny policy applies ...') that Claude largely already knows, so it could be tightened rather than fully lean.

2 / 3

Actionability

Provides fully executable, copy-paste-ready SQL throughout - 'ALTER TABLE accounts ENABLE ROW LEVEL SECURITY', 'ALTER TABLE accounts FORCE ROW LEVEL SECURITY', the worked 'CREATE POLICY tenant_isolation ON documents ... USING (...) WITH CHECK (...)', and concrete SET LOCAL test statements - matching the executable-code anchor.

3 / 3

Workflow Clarity

The 'How to use' section is a clear 7-step sequence with explicit validation checkpoints for the database operations - step 6 'assert cross-tenant reads and writes fail' and step 7 'Cross-check the policy against the Anti-patterns table before sign-off' - with the Testing section giving the concrete assertion/error to expect.

3 / 3

Progressive Disclosure

SKILL.md acts as a clear overview that signals one-level-deep references via markdown links - [references/create-policy-syntax.md], [references/tenant-context-patterns.md], [references/policy-and-bypass-patterns.md] - all verified to exist, with a dedicated References section summarizing each.

3 / 3

Total

11

/

12

Passed

Description

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.

A highly specific, third-person description that clearly states both its reference-catalog purpose and its use context, with strong natural trigger terms and minimal conflict risk. Every token earns its place and there is no vague fluff.

DimensionReasoningScore

Specificity

Lists many concrete subtopics and actions - 'enabling RLS (ALTER TABLE ... ENABLE ROW LEVEL SECURITY)', 'CREATE POLICY syntax (USING vs WITH CHECK clauses ... permissive vs restrictive)', 'bypassing RLS (superuser / BYPASSRLS / table owner / FORCE ROW LEVEL SECURITY)', 'performance discipline (wrapping auth functions in SELECT, index on policy-referenced columns)' - matching the multiple-specific-concrete-actions anchor.

3 / 3

Completeness

Explicitly answers what ('Pure-reference catalog of Postgres Row-Level Security (RLS) for tenant isolation. Covers ...') and when ('Use as the RLS-pattern reference for Postgres-backed tenant isolation. Consumed by tenant-leak-test-author, cross-tenant-data-leak-tests'), satisfying both halves with an explicit trigger clause.

3 / 3

Trigger Term Quality

Natural user-facing terms are well covered: 'Postgres Row-Level Security (RLS)', 'tenant isolation', 'CREATE POLICY', 'BYPASSRLS', 'Supabase auth.uid() / auth.jwt()' - the exact phrasing a user needing RLS would say, matching the good-coverage anchor.

3 / 3

Distinctiveness Conflict Risk

The niche is sharply defined - Postgres RLS for tenant isolation - and it names its sibling/consumer skills, making a wrong-skill trigger very unlikely; matches the clear-niche anchor.

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents