CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/crash-triage-reference

Reference catalog for triaging fuzzer crash artifacts - reading ASan, UBSan, and MSan output; classifying findings as LIKELY-EXPLOITABLE, MEDIUM, or BENIGN; deduplicating by stack-hash; minimizing reproducers with -minimize_crash; plus the bulk triage workflow for a full artifact directory (inventory, reproduce, classify, dedupe, BLOCK/PASS verdict with refuse-to-proceed rules and a report template). Use when you need to understand what a specific crash means, build exploitability intuition, work a set of findings by hand, or run a campaign-level triage that ends in a release verdict.

69

Quality

87%

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

81%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 actionable reference: copy-paste-ready commands, a comprehensive classification table, and a bulk workflow with genuine validation checkpoints and refuse-to-proceed guardrails. The main costs are token inefficiency from ~15 repeated inline URL citations plus a References section repeating them, Limitations entries duplicating body content, and a monolithic single-file layout that inlines material a leaner SKILL.md would point to.

Suggestions

Cite each LLVM document once in the References section and drop the inline 'per [url]' repetitions — the same four URLs are repeated multiple times within individual sections (e.g., the AddressSanitizer link appears four times in the ASan section alone).

Cut or merge the Limitations entries that restate body content: the AFL++ filename-encoding note and the MSan origin-tracking note both appear verbatim twice.

Consider moving the per-sanitiser reading guides and the report template into references/ files linked from SKILL.md so the top-level file reads as a navigable overview rather than a ~355-line monolith.

DimensionReasoningScore

Conciseness

The core content is dense and efficient (tables, annotated output, commands), but there is avoidable repetition: the same four LLVM URLs are cited inline roughly 15 times ('per [clang.llvm.org/docs/AddressSanitizer.html]' appears in the ASan intro, the key-fields table, the detection list, and the dedup section) on top of a References section that repeats all four, and the Limitations section restates the AFL++ filename note ('the class is not encoded in the filename' vs. 'AFL++ crash class is not in the filename') and the MSan origins note already made in the body. Not a 2 because nothing explains concepts Claude already knows and there is no padded prose; not a 4 because the citation repetition and duplicated notes are more than minor trims.

3 / 5

Actionability

Fully executable, copy-paste-ready commands with exact flags throughout: the stack-hash pipeline ('grep -E '^\s+#[0-9]+ 0x' ... | sha1sum | cut -c1-8'), minimization ('./fuzz_target -minimize_crash=1 -max_total_time=60 -exact_artifact_path=./minimized_crash ./crash-a3f2c1b0'), verification ('ASAN_OPTIONS=abort_on_error=1:symbolize=1 ... ./fuzz_target -runs=1'), and a complete report template. Specific examples cover the common cases (single crash, minimization, full-directory bulk triage).

5 / 5

Workflow Clarity

The bulk triage workflow is a clearly numbered 6-step sequence with explicit validation checkpoints: 'Reproduce every artifact against the current binary... never classify from memory', re-run after minimization 'to confirm it still triggers the same crash class and the same stack-hash', and refuse-to-proceed rules ('refuses to emit a PASS verdict while any unclassified artifact remains', 'refuses to... modify, delete, or minimise artifacts') that function as error-recovery guardrails for a batch operation. The anti-patterns table adds failure-mode feedback loops, matching the anchor-5 example's validate-fix-retry pattern.

5 / 5

Progressive Disclosure

Good structure: clear section headers, well-signaled one-level-deep external references ('see the sanitizer-integration reference in the sibling coverage-guided-fuzzing skill'; LLVM doc links), a dedicated References section, and no bundle files to mis-navigate (references/, scripts/, assets/ do not exist). Minor organization gap: all detail — the per-sanitiser reading guides, the classification table, and the report template — is inlined in a single ~355-line file rather than split into reference files, so SKILL.md is the detailed material rather than an overview. Not a 3 because navigation is easy and the external references are clearly signaled, not buried.

4 / 5

Total

17

/

20

Passed

Description

87%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 that explicitly and concretely states both what the skill does and when to use it, with a distinct niche and good natural keywords. The only deductions are the second-person phrasing in the trigger clause ('Use when you need to...'), which the rubric penalizes on specificity, and missing fuzzer-tool synonyms (libFuzzer, AFL++, cargo-fuzz) that users commonly say.

Suggestions

Rewrite the trigger clause in third person (e.g., 'Use when triaging fuzzer crash output, deduplicating crash findings, or deciding a release verdict from a fuzzing campaign') — 'Use when you need to...' is second person and cost specificity a point under this rubric.

Add the tool names users actually say as trigger terms — libFuzzer, AFL++, cargo-fuzz, 'sanitizer report', 'crash log' — since none currently appear in the description.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions ('reading ASan, UBSan, and MSan output; classifying findings as LIKELY-EXPLOITABLE, MEDIUM, or BENIGN; deduplicating by stack-hash; minimizing reproducers with -minimize_crash'), which is anchor-5 coverage. However, the trigger clause 'Use when you need to understand what a specific crash means' uses second person, and the rubric explicitly penalizes second-person voice by reducing specificity by 1, so an otherwise clear 5 becomes 4. It is not a 3 because the action list is comprehensive, not merely 1-2 actions.

4 / 5

Completeness

Explicitly answers both questions: the 'what' is a concrete catalog ('Reference catalog for triaging fuzzer crash artifacts - reading...; classifying...; deduplicating...; minimizing...; plus the bulk triage workflow... BLOCK/PASS verdict'), and the 'when' is an explicit 'Use when...' clause with concrete triggers ('understand what a specific crash means, build exploitability intuition, work a set of findings by hand, or run a campaign-level triage that ends in a release verdict'). Matches the anchor-5 example pattern exactly.

5 / 5

Trigger Term Quality

Good natural keyword coverage: 'fuzzer crash artifacts', 'ASan', 'UBSan', 'MSan', 'triage', 'dedupe', 'exploitability', 'release verdict' are phrases users would naturally say. A few common variations are missing — the tool names users actually mention ('libFuzzer', 'AFL++', 'cargo-fuzz', 'sanitizer report', 'crash log') appear nowhere in the description. Not a 5 because of those missing synonyms; clearly above the 'some relevant keywords' midpoint of 3.

4 / 5

Distinctiveness Conflict Risk

Clear niche (triaging fuzzer/sanitiser crash artifacts) with distinct trigger vocabulary unlikely to collide with other skills; it even scopes adjacent work away ('for sanitiser build flags and compatibility, see the sanitizer-integration reference in the sibling coverage-guided-fuzzing skill'), reducing overlap risk further. Minimal conflict risk.

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

Table of Contents