CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/mvcc-isolation-tests

Use when two concurrent database transactions can touch the same rows (balance debits, seat bookings, stock counts), or before changing a default isolation level. Tests which anomalies each level prevents (dirty, non-repeatable and phantom reads, write skew) in PostgreSQL, MySQL and SQL Server.

Quality

93%

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

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

An excellent code-skill body: a complete executable test harness with deterministic interleaving, explicit validation checkpoints (Step 4's mutation tests and per-test fixture assertions), and a clean one-level-deep split of per-database differences into references/per-database.md. The only reducible cost is a version-specific provenance claim and minor comment redundancy in an otherwise lean document.

DimensionReasoningScore

Conciseness

The body teaches nothing Claude already knows — the anomaly and anti-pattern tables are dense, and code comments carry non-obvious information ('a wait that times out fails the test instead of hanging'). Minor trimmable instances keep it below lean: the version-specific claim "ran 5/5 green on PostgreSQL 16 with psycopg 3" and a few redundant inline comments. Not 3, since there is no padded explanation or concept teaching anywhere.

4 / 5

Actionability

The skill provides a complete, copy-paste-ready pytest file — imports, schema fixture, two-connection harness with timeouts, four anomaly tests, and a retry wrapper — plus the exact invocation `TEST_DSN=... pytest tests/db/test_isolation.py`. Fully executable and covering the common cases, matching the top anchor; not 4 because there are no gaps in executability.

5 / 5

Workflow Clarity

Steps 1–4 are clearly sequenced, and Step 4 is an explicit validation checkpoint checklist ('must fail when you raise the isolation level by one step. Try it.'). Feedback loops are present throughout (fixture asserts starting counts, hang detection, throwaway-database warning for the destructive drop/recreate), so the destructive-operation cap does not apply. Not 4: validation is explicit and built in as a dedicated step with mutation-style checks.

5 / 5

Progressive Disclosure

The bundle's single reference, references/per-database.md, exists and is well-signaled at three points ('Other databases differ', the anti-patterns table, and the References list), exactly one level deep with no nesting. Database-specific differences are appropriately split out while the core test content stays in SKILL.md, and section navigation is easy. Not 4: there are no organization gaps or buried references.

5 / 5

Total

19

/

20

Passed

Description

91%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 strong description with an explicit 'Use when' trigger clause listing concrete business scenarios (balance debits, seat bookings, stock counts) and a clear, enumerated statement of what it does across three named databases. The only weaknesses are a single-verb capability set and slight overlap risk with adjacent concurrency-testing skills.

DimensionReasoningScore

Specificity

"Tests which anomalies each level prevents (dirty, non-repeatable and phantom reads, write skew) in PostgreSQL, MySQL and SQL Server" names the action concretely with enumerated anomaly types and three databases, matching the 'several specific actions; minor gaps' anchor. It is not 5 because the capability set reduces to a single verb ('tests') rather than multiple distinct actions, and not 3 because the enumeration is far more concrete than '1-2 concrete actions'.

4 / 5

Completeness

It explicitly answers both: what ("Tests which anomalies each level prevents… in PostgreSQL, MySQL and SQL Server") and when ("Use when two concurrent database transactions can touch the same rows… or before changing a default isolation level") with concrete trigger phrases, exactly matching the anchor-5 example. Not 4, because the 'when' clause is fully explicit and specific rather than improvable.

5 / 5

Trigger Term Quality

Natural user phrases are comprehensively covered: "balance debits, seat bookings, stock counts", "isolation level", "concurrent database transactions", all four anomaly names, and all three database names — synonym-level coverage matching the top anchor. A 4 would require noticeable missing natural terms, which is not the case here.

5 / 5

Distinctiveness Conflict Risk

The isolation-level anomaly-testing niche is clear and distinct, but "two concurrent database transactions can touch the same rows" has minor overlap risk with closely related concurrency skills (race-condition, deadlock, locking). Fits 'mostly distinct; minor overlap risk' better than the 'minimal conflict risk' of 5.

4 / 5

Total

18

/

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

On this page