CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/async-ordering-tests

Test async ordering - event-loop / queue / channel ordering assertions, JS Promise microtask vs macrotask ordering, Python `asyncio.gather` vs `asyncio.wait_for` semantics, Go goroutine + channel happens-before relationships, async/await re-entrancy. Use deterministic schedulers (sinon fake timers, asyncio test mode) to remove run-to-run variance. Use when a callback fires twice, a later response overwrites an earlier one, or a cancelled parent task leaves a child still running - bugs where completion order, not shared memory, is the defect.

89

0.98x
Quality

87%

Does it follow best practices?

Impact

98%

0.98x

Average score across 3 eval scenarios

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 well-organized, example-driven reference: every section delivers an executable test pattern with explicit assertions, and the anti-patterns table and Limitations section add real practical value. Weaknesses are modest — a couple of concept re-explanations, a few snippets that aren't fully self-contained (missing imports, cross-snippet references), 'Step' labels on what is really a scenario catalog, and no progressive-disclosure layering for a file of this length.

Suggestions

Trim the concept re-explanations in Step 1 (microtask queue semantics) and Step 6 (the happens-before chain recap) — the inline code comments already convey both, and Claude knows these runtime rules.

Make snippets self-contained for copy-paste readiness: add 'import pytest' (and asyncio import context) to Step 8, and define trackedFetch inside the sequential-await test in Step 3.

Relabel 'Step 1–8' as scenario-based headers (e.g., 'JS microtask vs macrotask', 'Python gather ordering') or add a short symptom-to-pattern index, since the sections are a catalog to select from, not a sequence to execute.

DimensionReasoningScore

Conciseness

The body is mostly lean — each section is a tight code example plus 1–3 sentences of practical guidance ('Real timers + sleep = flake. Fake timers = deterministic.'), with a dense anti-patterns table and genuinely non-obvious Limitations. Minor over-explanation could be trimmed: Step 1's 'Critical: promise resolution callbacks run in the microtask queue, which drains *between* macrotasks' and Step 6's happens-before chain recap both restate concepts Claude already knows and duplicate the inline code comments, keeping this just below anchor 5.

4 / 5

Actionability

All eight patterns are real, executable tests (vitest fake timers, Promise.all order tracking, asyncio.gather/wait, Go channel happens-before with 'go test -race', backpressure, cancellation propagation) — no pseudocode. Minor gaps keep it at anchor 4 rather than 5: Step 8 uses pytest.raises without importing pytest, and the sequential-await snippet in Step 3 references trackedFetch defined only in the preceding test's scope.

4 / 5

Workflow Clarity

Structure is clear and navigable: a 'When to use' entry section, eight well-formed pattern sections, and an anti-patterns table that maps failures to specific fixes with step cross-references, with each test carrying explicit assertion checkpoints. It stops short of anchor 5 because the sections are labeled 'Step 1–8' although they form a catalog of scenarios rather than a sequence, and there is no explicit symptom-to-pattern decision flow beyond the anti-patterns table; it clearly exceeds anchor 3 since validation is inherent in the test assertions and every section is self-contained.

4 / 5

Progressive Disclosure

The single file has well-organized headers, a References section pointing to canonical sources (ECMAScript spec, asyncio docs, go.dev/ref/mem) and to sister skills, and no buried or nested references — nothing is unfindable. It does not reach anchor 5 because there is no disclosure structure at all: ~260 lines of per-language test patterns are all inlined in SKILL.md (no references/ or scripts/ files exist) where a JS/Python/Go split could keep the overview leaner; it stays above anchor 3 because the inline content is genuinely usable and every section is clearly signaled.

4 / 5

Total

16

/

20

Passed

Description

92%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, highly specific description that names concrete capabilities across JS, Python, and Go, states the method (deterministic schedulers), and includes an explicit 'Use when' clause with realistic bug-symptom triggers and a clear boundary against shared-memory race-condition skills. The only weakness is a few missing natural trigger phrasings (e.g., 'flaky test', 'race condition') users commonly use for this problem.

DimensionReasoningScore

Specificity

The description lists many concrete, named capabilities — 'event-loop / queue / channel ordering assertions', 'JS Promise microtask vs macrotask ordering', 'Python asyncio.gather vs asyncio.wait_for semantics', 'Go goroutine + channel happens-before relationships', 'async/await re-entrancy', and 'Use deterministic schedulers (sinon fake timers, asyncio test mode)' — giving comprehensive, ecosystem-specific coverage. Voice is third-person/imperative throughout, so no person-penalty applies; it exceeds anchor 4 because there are no coverage gaps across the three target ecosystems.

5 / 5

Completeness

It explicitly answers both questions: the 'what' via named ordering-assertion capabilities and the method ('Use deterministic schedulers ... to remove run-to-run variance'), and the 'when' via a concrete 'Use when' clause listing three specific bug symptoms and the boundary 'bugs where completion order, not shared memory, is the defect'. This matches anchor 5's requirement of concrete trigger phrases for both what and when.

5 / 5

Trigger Term Quality

Natural symptom phrases users would actually say are present — 'a callback fires twice', 'a later response overwrites an earlier one', 'a cancelled parent task leaves a child still running' — plus exact tool names (Promise, asyncio.gather, goroutine, sinon fake timers). It falls short of anchor 5 because common user phrasings like 'flaky test', 'race condition', or 'intermittent/nondeterministic test failure' are absent, though it clearly beats anchor 3's partial coverage.

4 / 5

Distinctiveness Conflict Risk

The description carves a sharp niche — async/runtime-scheduler ordering tests — and explicitly disambiguates from adjacent skills with 'bugs where completion order, not shared memory, is the defect', separating it from general race-condition/data-race skills. Trigger symptoms (double-firing callbacks, overwrite ordering, cancelled-parent child leaks) are distinctive enough that anchor 5's minimal-conflict bar is met.

5 / 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