CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/fuzz-tool-selector

Routes a fuzz-target authoring task to the right fuzzer for the detected language and build type. Decision tree: C/C++ → libfuzzer-cpp + afl-plus-plus; Rust → cargo-fuzz-rust (or libfuzzer-cpp via FFI); Go → go-native-fuzzing; Python → atheris-python-fuzzing; JVM → jazzer-jvm-fuzzing; closed-source binary → afl-plus-plus in QEMU mode; mature open-source project → ossfuzz-integration. Use when a project needs coverage-guided fuzzing and no fuzzer has been chosen for its language or toolchain yet.

75

Quality

94%

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 well-structured, actionable routing skill with a clear decision workflow and explicit anti-pattern guidance. The only weakness is token efficiency: the routing logic is presented in three overlapping forms, creating redundancy that could be consolidated.

Suggestions

Consolidate the routing logic: the ASCII decision tree, the Routing rules table, and the per-language Routing rationale all express the same routing — keep one canonical quick-reference (the table) and fold the tree's flow into the rationale to remove triplication.

In the Routing rationale, drop incidental attributions that don't affect the routing decision (e.g. "Google's libFuzzer-backed Python fuzzer", "Code Intelligence's libFuzzer-backed JVM fuzzer") to tighten the prose.

If the ASCII decision tree is retained for visual flow, trim the Routing rules table to only the cases the tree does not already cover, so each representation earns its place.

DimensionReasoningScore

Conciseness

Mostly efficient and free of concept over-explanation, but the core routing logic is restated three times — the ASCII decision tree, the Routing rules table, and the per-language Routing rationale — which could be tightened. It is not the lean 'every token earns its place' level above.

2 / 3

Actionability

The Routing rules table gives concrete, copy-paste-ready decisions (e.g. "C / C++ library with callable function API → libfuzzer-cpp") and the Anti-patterns table pairs each failure with a specific Fix, providing fully actionable guidance for an instruction-only routing skill.

3 / 3

Workflow Clarity

The decision tree lays out an explicit three-step sequence (identify language → route by characteristic → OSS-Fuzz overlay). This is a selection task with no destructive/batch operation, so the absence of a validation checkpoint does not cap the score.

3 / 3

Progressive Disclosure

The body is organized into clearly headed sections (Overview, When to use, Decision tree, Routing rules, Routing rationale, Anti-patterns, Limitations, References) and the References section clearly signals the composed skills and references. No bundle files exist to verify, and the organization alone supports easy navigation.

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 strong, specific description that explicitly states what it routes, when to use it, and the per-language decision outcomes. Third-person voice is maintained and the explicit 'Use when' clause satisfies the completeness ceiling. No changes needed.

DimensionReasoningScore

Specificity

Names multiple concrete routing actions per language ("C/C++ → libfuzzer-cpp + afl-plus-plus", "Rust → cargo-fuzz-rust", "closed-source binary → afl-plus-plus in QEMU mode"), matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Clearly answers both what ("Routes a fuzz-target authoring task to the right fuzzer") and when with an explicit "Use when a project needs coverage-guided fuzzing and no fuzzer has been chosen" trigger clause.

3 / 3

Trigger Term Quality

Uses natural terms a developer needing fuzzing would say — "coverage-guided fuzzing", "fuzzer", "language", "toolchain", "fuzz-target" — giving good coverage rather than jargon-only phrasing.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (fuzzer selection routing) with a distinct trigger ("no fuzzer has been chosen for its language or toolchain"), making conflict with other skills unlikely.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents