CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/race-condition-test-author

Build deterministic race-condition tests - identify shared mutable state, drive interleavings via barriers / latches / manual scheduling; use ThreadSanitizer (clang `-fsanitize=thread`) for C/C++ data race detection; run the Go race detector end-to-end (`go test -race`, GORACE tuning, `-count`/`-cpu` stress, goroutine-leak gating with go.uber.org/goleak - references/go.md); use jcstress (`@JCStressTest` + `@Actor` + `@Outcome`) for JVM stress; use Loom virtual-thread interleavings for parallel testing. Use when a defect only reproduces under load on shared in-process state (cache, counter, connection pool, lazy-init singleton), when writing the regression test for a race-condition incident before the fix lands, or when adding `-race` to a Go CI matrix.

74

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

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

Strong, highly actionable body: every step ships complete executable code or commands across six ecosystems, sequenced clearly with a checklist and anti-patterns table. The main improvement room is in trimming known-concept framing, adding explicit red/green validation checkpoints for regression tests, and evening out the reference-file split.

Suggestions

Trim known-concept framing that Claude does not need - e.g. "Virtual threads run M:N on OS threads..." and the jcstress self-description quote - keeping only harness-specific facts (flags, annotations, overhead numbers) to lift conciseness.

Add explicit validation checkpoints to the workflow: confirm a regression test fails without the fix and passes with it before landing, and specify a repeat/stress-run count (e.g. -count or iteration guidance) before trusting a green sanitizer run, rather than only hinting at this in the anti-patterns table.

Even out progressive disclosure: surface references/goleak-filter-options.md directly from the SKILL.md References section (it is currently two hops deep via go.md), and consider moving the jcstress/Loom/TSan option detail into reference files for parity with how the Go workflow is split.

DimensionReasoningScore

Conciseness

The body is code-heavy and mostly lean, but a few sentences restate concepts Claude already knows: "Race conditions are the canonical 'works on my machine, breaks under load' bug", "Virtual threads run M:N on OS threads - the JVM scheduler interleaves them aggressively", and the jcstress self-description quote ("the experimental harness ... for the correctness of concurrency support in the JVM"). These are trimmable over-explanations (anchor 4), but there is no padded section or basic-concept teaching at length, so it is clearly above anchor 3.

4 / 5

Actionability

Seven concrete, complete code/command blocks cover the common cases across Python (barrier test), C/C++ (clang/cmake TSan flags), Go (go test -race), JVM (a full @JCStressTest class), Java 21+ Loom, property-based testing, and CI YAML - e.g. `clang -fsanitize=thread -g -O1 program.c -o program` and `java -jar jcstress.jar -m quick CounterTest`. The only placeholders (LazyService(), ThreadSafeCounter()) are inherent to writing tests against user code, and every block is otherwise copy-paste ready, matching the fully-executable anchor rather than the minor-gaps anchor 4.

5 / 5

Workflow Clarity

A coherent numbered sequence runs Step 1-7 (identify shared state → deterministic interleaving → sanitizers → stress variants → CI), with a Step 1 code-review checklist, an anti-patterns table for recovery guidance, and sample "WARNING: DATA RACE" output teaching result recognition. However, explicit validation checkpoints are missing - e.g. confirm a regression test fails without the fix and passes with it, or a repeat-run count before trusting a green run - so it lands at anchor 4 rather than the explicit-checkpoint/feedback-loop anchor 5.

4 / 5

Progressive Disclosure

The heaviest content (the full Go workflow: GORACE, stress amplification, goleak gating, CI matrix) is properly externalized to the real file references/go.md with a clear inline pointer, and all referenced paths resolve. But the reference chain SKILL.md → go.md → goleak-filter-options.md runs two hops deep, and per-stack detail of comparable depth (TSan options, jcstress, Loom) remains inline, making the split uneven - good structure with minor organization gaps (anchor 4) rather than the strictly one-level-deep, evenly split anchor 5.

4 / 5

Total

17

/

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.

An exemplary description: it enumerates concrete, flag-level capabilities across every relevant stack, provides an explicit "Use when" clause with three realistic trigger scenarios, and stays dense with no fluff. All four dimensions sit at the top anchors.

DimensionReasoningScore

Specificity

Lists multiple concrete actions with exact tool flags across all major stacks: "Build deterministic race-condition tests - identify shared mutable state, drive interleavings via barriers / latches", "use ThreadSanitizer (clang `-fsanitize=thread`)", "run the Go race detector end-to-end (`go test -race`, GORACE tuning, `-count`/`-cpu` stress, goroutine-leak gating with go.uber.org/goleak)", "use jcstress (@JCStressTest + @Actor + @Outcome)", and Loom virtual-thread interleavings. Coverage is comprehensive with no material gap, so it matches the score-5 anchor rather than the 4 anchor ("minor gaps in coverage").

5 / 5

Completeness

Clearly answers both questions: the "what" is five concrete verb-phrases spanning C/C++, Go, and JVM tooling, and the "when" is an explicit "Use when..." clause with three concrete trigger scenarios (load-only reproduction on shared state, race-condition incident regression test, adding -race to a Go CI matrix). This matches the score-5 anchor exactly; the "missing Use when" cap does not apply.

5 / 5

Trigger Term Quality

Core synonyms users would naturally say are all present: "race-condition", "data race detection", "race detector", "-race", plus a natural symptom phrasing ("a defect only reproduces under load on shared in-process state (cache, counter, connection pool, lazy-init singleton)") and scenario terms ("regression test for a race-condition incident", "adding `-race` to a Go CI matrix"). Only marginal colloquialisms ("flaky", "thread safety") are absent, which still fits the comprehensive-coverage anchor better than anchor 4.

5 / 5

Distinctiveness Conflict Risk

Clear niche (data races on shared in-process state) with distinct, symptom-based triggers and named sanitizers, which keeps it from firing for general load/stress testing or for the closely related sister skills (deadlock detection, async ordering). Verb-first third-person voice, no generic filler, so it sits at the minimal-conflict anchor rather than the minor-overlap anchor 4.

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents