CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/mvcc-isolation-tests

Build per-database MVCC isolation-level tests - Read Uncommitted vs Read Committed vs Repeatable Read vs Serializable; verify which anomalies are prevented at each level (dirty read, non-repeatable read, phantom read, serialization anomaly, write skew). Per PostgreSQL transaction isolation docs; analogous patterns for MySQL InnoDB, SQL Server, and DynamoDB. Use when two concurrent transactions can touch the same rows (balance debit, seat booking, stock decrement), or before changing a service's default isolation level.

70

Quality

88%

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

75%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 strong, dense test-authoring guide: near-executable harness and per-anomaly tests, correct PG-specific subtleties (snapshot isolation, write skew, serialization abort/retry), and useful anti-pattern and per-DB tables. It uniformly falls just short of top marks on code completeness (undefined fixtures, one placeholder test), and on trimming known-concept recap and repeated attribution phrases.

Suggestions

Define the fixture helpers (setup_balance, setup_orders, setup_doctors, count_on_call) — or show one example implementation — so the tests in Steps 4-7 are copy-paste runnable rather than requiring the reader to invent the fixtures.

Replace the five repeated "Per the [PostgreSQL transaction isolation docs]" attributions with a single citation, and trim the standard anomaly-catalog/matrix tables to only the non-obvious deviations (e.g., PG's Repeatable Read preventing phantoms), which is what Claude does not already know.

Fill in the Step 9 test_serializable_retry_completes placeholder and integrate the deterministic barrier variant into the Step 3 harness code instead of leaving it as a comment sketch, so the timing-flake fix is directly actionable.

DimensionReasoningScore

Conciseness

Overall efficient — tables and code instead of prose, no library-tutorial padding, and genuinely non-obvious content (the PG snapshot-isolation quirk, the deterministic barrier variant, the write-skew note). But it includes a standard anomaly catalog and isolation matrix Claude already knows, plus the attribution phrase "Per the [PostgreSQL transaction isolation docs]" repeated five times — minor over-explanation that could be trimmed, matching the anchor-4 'Efficient; minor instances of over-explanation' rather than the lean anchor-5.

4 / 5

Actionability

The two-connection harness and the tests in Steps 4-7 are near-executable psycopg code with real assertions, and Step 9's retry pattern with exponential backoff is concrete. Minor gaps keep it below 'fully executable; copy-paste ready': the fixture helpers (setup_balance, setup_doctors, count_on_call) are called but never defined, the Step 9 test is a `...` placeholder, and the deterministic barrier variant is only a comment sketch.

4 / 5

Workflow Clarity

A clearly sequenced nine-step build-up (catalog → matrix → harness → per-anomaly tests → per-DB differences → retry) where each test carries explicit assertions as checkpoints, and Step 9 provides a catch/rollback/retry feedback loop appropriate for database operations. Minor gaps: no explicit run-and-verify-the-suite step, and the flakiness fix is presented as an aside rather than integrated into the harness — fits anchor 4 'Clear sequence with most checkpoints present; minor validation gaps' rather than the checklist-complete anchor 5.

4 / 5

Progressive Disclosure

No bundle files exist, and the ~290-line body is a single coherent guide with well-organized sections (Steps 1-9, Anti-patterns, Limitations, References) and clearly signaled external links. Minor organization gaps: the description promises "analogous patterns for MySQL InnoDB, SQL Server, and DynamoDB" but the body only summarizes them in a table, and the References section has slightly malformed formatting (dangling dash before "in-process concurrency siblings"). This matches anchor 4 'Good structure; most content appropriately placed; minor organization gaps'.

4 / 5

Total

16

/

20

Passed

Description

96%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.

An excellent description: concrete, comprehensive, third-person, with an explicit 'Use when' clause carrying concrete scenario triggers. The only weakness is that the when-clause is broad enough to overlap with generic concurrency-testing skills.

DimensionReasoningScore

Specificity

Multiple concrete actions are stated — "Build per-database MVCC isolation-level tests" and "verify which anomalies are prevented at each level" — with comprehensive enumeration: all four isolation levels ("Read Uncommitted vs Read Committed vs Repeatable Read vs Serializable"), five named anomalies ("dirty read, non-repeatable read, phantom read, serialization anomaly, write skew"), and four target databases ("MySQL InnoDB, SQL Server, and DynamoDB"). This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage'; there are no coverage gaps that would justify a 4.

5 / 5

Completeness

Explicitly answers both questions: what ("Build per-database MVCC isolation-level tests... verify which anomalies are prevented at each level") and when ("Use when two concurrent transactions can touch the same rows (balance debit, seat booking, stock decrement), or before changing a service's default isolation level"). This mirrors the anchor-5 example's structure of concrete what-clause followed by explicit 'Use when' trigger phrases.

5 / 5

Trigger Term Quality

Dense with natural domain terms a user would actually say: "isolation level", "MVCC", "phantom read", "serializable", "concurrent transactions", plus concrete scenario triggers ("balance debit, seat booking, stock decrement") and database names. Isolation-level names and anomaly names are given with their synonyms, matching the 'comprehensive coverage of natural terms including synonyms' anchor.

5 / 5

Distinctiveness Conflict Risk

The niche (isolation-level testing) is clear and distinct, but the when-clause "two concurrent transactions can touch the same rows" is a broad generic-concurrency trigger that would also fire for closely related race-condition/concurrency-testing skills. This fits 'Mostly distinct; minor overlap risk with closely related skills' (4) better than the anchor-5 'distinct triggers; minimal conflict risk', since the trigger is broader than the niche.

4 / 5

Total

19

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents