CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/deadlock-detection-harness

Build deadlock-detection harnesses - extract lock-acquire-order graph via instrumentation, run cycle detection (DFS) to spot inconsistent ordering, use lock-acquire timeouts to surface rather than hang, JVM `jstack` / `gdb thread apply all bt` for postmortem analysis. Pair with ThreadSanitizer's `detect_deadlocks=1` for runtime detection. Use when a service that holds two or more locks hangs in production with no crash or error, or before release when lock acquisition order across code paths has never been proven consistent.

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

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A tightly structured, highly actionable procedural skill that walks through lock-order convention, instrumentation, graph-based cycle detection, timeouts, TSan, postmortem analysis, and fingerprinting with executable code and validation at each step. The only weakness is mild verbosity from explaining a deadlock concept Claude already knows.

Suggestions

Remove or compress the opening deadlock definition ('A deadlock = a cycle in the lock-wait graph: thread A holds X waiting for Y...'); Claude already knows what a deadlock is, so lead directly with the harness method.

Tighten the redundant framing line ('Tests prevent deadlocks via static analysis of lock acquisition order + runtime detection') since the numbered Step 1–8 list that follows already conveys this.

Fold Step 2's 'rough sketch using contextvars + decorator' caveat into a one-line note so the section reads as authoritative rather than provisional.

DimensionReasoningScore

Conciseness

Mostly efficient and code-dense, but it opens by defining a deadlock ("A deadlock = a cycle in the lock-wait graph: thread A holds X waiting for Y; thread B holds Y waiting for X") — a concept Claude already knows — and re-states the method, so it could be tightened per the 'penalize concepts Claude knows' guideline.

2 / 3

Actionability

Each step ships real, executable Python (OrderedLock, build_lock_graph, find_cycles, fingerprint_acquire, timed-acquire test) plus concrete commands (TSAN_OPTIONS=detect_deadlocks=1, jstack, gdb thread apply all bt), matching the copy-paste-ready anchor.

3 / 3

Workflow Clarity

Eight numbered steps give a clear sequence, and each step embeds an assertion-based test (assert cycles == [], assert acquired, assert len(fps) <= 5) as an explicit validation checkpoint, with an anti-patterns table serving as a checklist.

3 / 3

Progressive Disclosure

No bundle files exist; the body is well-organized into sequenced sections with clearly signaled one-level-deep external references (the [TSan docs] link and sibling skills race-condition-test-author / async-ordering-tests), avoiding nested or poorly-signaled references.

3 / 3

Total

11

/

12

Passed

Description

100%

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 precise, third-person description that names concrete detection techniques and pairs them with an explicit, naturally-worded trigger clause covering both production-hang and pre-release scenarios. It is concise without over-claiming and occupies a distinct niche.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "extract lock-acquire-order graph via instrumentation", "run cycle detection (DFS)", "use lock-acquire timeouts", and "jstack / gdb thread apply all bt for postmortem analysis" — matching the 'multiple specific concrete actions' anchor.

3 / 3

Completeness

Explicitly answers both what (build harnesses via the listed detection techniques) and when ("Use when a service that holds two or more locks hangs in production... or before release when lock acquisition order across code paths has never been proven consistent"), satisfying the both-what-and-when anchor.

3 / 3

Trigger Term Quality

Natural trigger terms a user would say are well covered — "deadlock", "hangs in production", "locks", "lock acquisition order" — alongside an explicit triggering situation, so it is not merely technical jargon.

3 / 3

Distinctiveness Conflict Risk

Deadlock/lock-order detection is a clear niche with distinct triggers (multi-lock production hang, unproven lock-acquisition order) unlikely to fire for unrelated skills.

3 / 3

Total

12

/

12

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