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.

65

Quality

82%

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

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

The body is an efficient, actionable reference with executable two-connection test harnesses for each isolation level and a thoughtful write-skew treatment. Its main weakness is the absence of explicit validation checkpoints for destructive database operations, which caps workflow clarity.

Suggestions

Add an explicit validation step between destructive tests (e.g., 'reset fixtures via TRUNCATE/seed before each test; assert row counts pre/post') to satisfy the database-operations feedback-loop requirement.

Fill in the test_serializable_retry_completes stub and define setup_balance/setup_orders/setup_doctors/count_on_call helpers so every example is runnable as-is.

Consider moving the per-database differences table (Step 8) and retry pattern (Step 9) into referenced files to reduce inline length and aid navigation.

DimensionReasoningScore

Conciseness

Dense, procedural, and assumes Claude knows SQL/Python; every section earns its place, though a few embedded docstrings and assert comments could be trimmed slightly.

4 / 5

Actionability

Provides copy-paste-ready Python for the harness and tests across isolation levels, but test_serializable_retry_completes is a stub and setup_*/count_on_call helpers are undefined — minor gaps.

4 / 5

Workflow Clarity

Steps 1-9 are clearly sequenced with a deterministic-flake variant and accepted-outcome rationale, but destructive/batch database operations lack explicit validation checkpoints (e.g., fixture-reset verification between runs), which caps this dimension at 3 per the rubric.

3 / 5

Progressive Disclosure

Single cohesive file with well-organized sections, tables, and a clearly signaled References section; no nested references, but at ~290 lines a couple of sections (per-DB matrix, retry pattern) could be split into referenced files.

4 / 5

Total

15

/

20

Passed

Description

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

The description is strong: it explicitly answers both what and when, names concrete scenarios and multi-database scope, and avoids fluff. The only gaps are a few missing trigger synonyms and slight overlap risk with generic concurrency-testing skills.

Suggestions

Add common trigger synonyms such as 'concurrency', 'race condition', and 'locking' to broaden natural keyword coverage.

Sharpen distinctiveness by noting what is out of scope (e.g., 'not for deadlock detection — see deadlock-detection-harness').

DimensionReasoningScore

Specificity

Lists multiple concrete actions (build per-database isolation tests, verify which anomalies are prevented) across all four SQL levels, five anomaly types, and four databases — comprehensive coverage matching the top anchor.

5 / 5

Completeness

Explicitly states what ('Build per-database MVCC isolation-level tests... verify which anomalies are prevented') and when ('Use when two concurrent transactions can touch the same rows... or before changing a service's default isolation level') with concrete trigger phrases.

5 / 5

Trigger Term Quality

Includes natural trigger phrases ('balance debit, seat booking, stock decrement', 'changing a service's default isolation level') but omits common synonyms like 'concurrency', 'race condition', and 'locking'.

4 / 5

Distinctiveness Conflict Risk

A clear niche (per-database MVCC isolation testing) with distinctive triggers, but minor overlap risk with generic concurrency-test siblings like race-condition-test-author.

4 / 5

Total

18

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Reviewed

Table of Contents