Lean body that assumes competence: no explaining what RLS or a database is, each section opens with the isolation primitive and gives minimal executable SQL, and version numbers are confined to external reference links rather than inlined.

Each engine section ships executable SQL annotated with expected outcomes (e.g. '-- must be denied', '-- violates WITH CHECK', '-- fails: key is read-only'), and the anti-patterns table pairs each failure mode with a concrete fix.

This is a reference/catalog skill whose single action (look up an engine's isolation mechanism and tests) is unambiguous via the cheat sheet plus per-engine sections; per the simple-skills note workflow clarity can score 3, and no destructive batch operation is present to require validation checkpoints.

A concise overview and cheat sheet lead into four well-signaled one-level-deep references (e.g. '[references/mysql-mariadb.md](references/mysql-mariadb.md)'); the referenced files exist and link only to external docs, with no nested .md chaining.

Names multiple concrete actions per engine, e.g. 'ALTER TABLE ENABLE ROW LEVEL SECURITY and CREATE POLICY', 'CREATE SECURITY POLICY with inline table-valued function filter/block predicates', and 'keyspace sharding + vindexes route tenant writes to dedicated shards'.

Explicitly states what it covers ('Covers the isolation mechanism, tenant-context pattern, bypass risks, and test patterns for each engine') and when to use it ('Use when designing or auditing tenant isolation on ...'), satisfying both halves.

Includes the natural engine names users would say (MySQL, MariaDB, CockroachDB, Vitess, SQL Server) plus the trigger phrase 'Use when designing or auditing tenant isolation on ...'; coverage is broad and natural rather than jargon.

The four-engine row/tenant-isolation niche is highly specific and explicitly scoped as the non-Postgres complement to a Postgres skill, making accidental triggering of the wrong skill unlikely.