CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/coverage-guided-fuzzing

Coverage-guided fuzzing across every mainstream engine - libFuzzer (C/C++ in-process), AFL++ (out-of-process, QEMU mode for closed-source binaries), cargo-fuzz (Rust), Go native fuzzing (go test -fuzz), Atheris (Python), and Jazzer (JVM, @FuzzTest). Body covers choosing the right fuzzer for the language and build type (the routing tree) plus the engine-generic workflow: writing a small deterministic fuzz target, seed-corpus + dictionary construction, sanitizer selection (ASan + UBSan default, compatibility matrix), corpus minimisation, crash-artifact handling, and CI smoke-fuzz wiring with a cached corpus. Per-engine depth (flags, harness syntax, CI jobs) lives in references, as do the corpus-management and sanitizer-integration catalogs. Use when a project needs fuzz coverage and no fuzzer is chosen yet, or when authoring / running / maintaining a fuzz campaign with any of these engines. For triaging the resulting crashes see crash-triage-reference.

70

Quality

88%

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

78%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-organised umbrella skill that routes engines, lays out a concrete five-step workflow, and offloads per-engine depth to verified references. Main gaps are the redundant ASCII diagram and the crash feedback loop living in a sibling rather than inline.

Suggestions

Drop or shrink the ASCII routing tree — the routing table immediately below it conveys the same routing more compactly and the diagram adds tokens without new information.

Add a one-line inline feedback loop for crashes (detect → minimise → triage via crash-triage-reference) so the workflow is self-contained for the most common error path.

Inline a single representative harness skeleton (e.g. a libFuzzer LLVMFuzzerTestOneInput stub) so the body is copy-paste ready for at least the most common engine.

DimensionReasoningScore

Conciseness

Dense and assumption-respecting with no basic-concept padding and a one-line overview; the ASCII routing tree is partly redundant with the immediately following routing table and could be trimmed, keeping it just shy of fully lean.

4 / 5

Actionability

Provides a copy-paste CI yaml block and concrete flags (-fsanitize=fuzzer,address,undefined -fno-sanitize-recover=all, -merge=1 / afl-cmin, go test -race), but harness syntax itself is delegated to references so it is not fully copy-paste across the common cases.

4 / 5

Workflow Clarity

Clear Step 1–5 sequence with checkpoints ('Run locally until coverage plateaus', 'minimise every crash input before filing it'); the crash feedback loop is offloaded to the crash-triage sibling rather than inline, so explicit error-recovery loops are absent.

4 / 5

Progressive Disclosure

Overview body points to eight one-level-deep reference files via clearly signalled markdown links, all of which exist, with per-engine depth and catalogs appropriately split out and easy to navigate.

5 / 5

Total

17

/

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 dense, well-structured description that concretely states capabilities and explicit use-when triggers with minimal conflict risk. Only slight weakness is a few missing natural synonyms in the trigger phrasing.

DimensionReasoningScore

Specificity

Lists multiple concrete actions across the whole workflow — 'writing a small deterministic fuzz target, seed-corpus + dictionary construction, sanitizer selection (ASan + UBSan default, compatibility matrix), corpus minimisation, crash-artifact handling, and CI smoke-fuzz wiring' plus engine routing, giving comprehensive coverage.

5 / 5

Completeness

Explicitly answers both what (named engines plus the engine-generic workflow steps) and when ('Use when a project needs fuzz coverage and no fuzzer is chosen yet, or when authoring / running / maintaining a fuzz campaign with any of these engines').

5 / 5

Trigger Term Quality

Good natural trigger phrases ('fuzz coverage', 'fuzz campaign', 'fuzz target', 'no fuzzer is chosen yet') but a few common synonyms users might say ('fuzz test', 'find crashes') are absent, so it sits just below comprehensive.

4 / 5

Distinctiveness Conflict Risk

Clear niche (coverage-guided fuzzing across six named engines) with distinct triggers and explicit sibling hand-off to crash-triage-reference, minimising overlap with adjacent skills.

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

DiscoveryImplementationValidation