CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/rls-reference

Pure-reference catalog of row-level security for tenant isolation, Postgres-first. 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()), and performance discipline (wrapping auth functions in SELECT, index on policy-referenced columns). Row/tenant isolation on the non-Postgres engines - MySQL / MariaDB invoker views, CockroachDB native RLS, Vitess vindex sharding, SQL Server security policies - lives in references/other-engines.md. Use as the RLS-pattern reference for tenant isolation on any of these engines. Consumed by 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

86%Weight 40%Scale 1-5

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

A well-structured reference skill with executable SQL, a validated multi-step workflow, and clean progressive disclosure into real bundle files. Minor tightening of explanatory prose and an explicit test-failure retry loop would raise it further.

Suggestions

Tighten the Overview and Worked example prose and drop redundant 'Per Postgres docs' lead-ins to improve conciseness.

Add an explicit 'if a cross-tenant test passes unexpectedly, revise the policy and re-run' retry step to the workflow to close the validation loop.

Consider inlining a one-line TOC mapping each body section to its reference file so navigation is even more discoverable.

DimensionReasoningScore

Conciseness

Largely lean — tables, code blocks, and targeted patterns with no basic-concept padding — but the Overview and Worked example prose, plus repeated 'Per Postgres docs' framing, could be trimmed slightly without losing value.

4 / 5

Actionability

Copy-paste-ready SQL throughout — ALTER TABLE ENABLE/FORCE, a full CREATE POLICY ... USING/WITH CHECK example, statement-level test queries with expected failure messages, and a Bad/Good auth.uid() snippet — covers the common cases concretely.

5 / 5

Workflow Clarity

The 7-step 'How to use' is clearly sequenced with a validation checkpoint (step 6: 'assert cross-tenant reads and writes fail') and an anti-patterns checklist (step 7), but an explicit validate→fix→retry loop for a failed test is implied rather than spelled out.

4 / 5

Progressive Disclosure

Body is a true overview pointing one level deep to real, topic-split bundle files (create-policy-syntax.md, tenant-context-patterns.md, policy-and-bypass-patterns.md, other-engines.md and its per-engine peers), all verified present and clearly signaled.

5 / 5

Total

18

/

20

Passed

Description

100%Weight 40%Scale 1-5

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 dense, specific, third-person description that answers what and when with concrete trigger phrases and natural terminology. It is comprehensive across enabling, policy, bypass, context, performance, and multi-engine coverage.

DimensionReasoningScore

Specificity

Lists multiple concrete capabilities with specifics — 'ALTER TABLE ... ENABLE ROW LEVEL SECURITY, default-deny semantics', 'USING vs WITH CHECK clauses', 'BYPASSRLS / table owner / FORCE ROW LEVEL SECURITY', 'wrapping auth functions in SELECT' — covering enabling, policy syntax, bypass, context, performance, and multi-engine isolation comprehensively.

5 / 5

Completeness

Explicitly answers both what ('Pure-reference catalog of row-level security for tenant isolation, Postgres-first') and when ('Use as the RLS-pattern reference for tenant isolation on any of these engines'), with a concrete consumer ('Consumed by cross-tenant-data-leak-tests').

5 / 5

Trigger Term Quality

Includes the natural terms a user would say — 'row-level security', 'RLS', 'tenant isolation', 'Postgres', plus engine names MySQL/MariaDB/CockroachDB/Vitess/SQL Server — with the synonym pair row-level security/RLS both present.

5 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (RLS for tenant isolation across named engines) with distinct triggers and minimal overlap risk with other skills.

5 / 5

Total

20

/

20

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