CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/ossfuzz-integration

Author and submit a project to Google OSS-Fuzz - the open-source continuous fuzzing service that runs libFuzzer / AFL++ / Honggfuzz campaigns on Google infrastructure 24x7. Covers the project.yaml + Dockerfile + build.sh contract, the $OUT/$WORK conventions, supported languages + sanitisers, seed-corpus + dictionary submission, the OSS-Fuzz Build Status dashboard, and the disclosure SLA (issues filed in Monorail with 90-day deadline). Use to offload long-running fuzz campaigns to dedicated infrastructure rather than self-hosting.

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

Low

Low-risk findings worth noting

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.

The body is highly actionable with a clear, validated workflow and good progressive disclosure to a real reference file. Its main weakness is moderate redundancy between the Overview, Authoring, and Submitting sections and the description, which keeps conciseness just below the top anchor.

Suggestions

Collapse the repeated project.yaml/Dockerfile/build.sh contract mentions in Overview and Authoring into a single pointer to the How-to-use steps and the reference file, since the same triple is named in three places.

Remove the restated '24x7 on Google Cloud across multiple sanitiser configurations (ASan, UBSan, MSan)' facts from the Overview body, as they already appear verbatim in the description frontmatter.

Merge the 'Submitting a new project' subsection's PR-and-review steps with the 'How to use' numbered list to avoid two parallel descriptions of the same submission flow.

DimensionReasoningScore

Conciseness

The body is largely efficient and assumes Claude's competence, but the Overview, Authoring, and Submitting sections partly restate the same project.yaml/Dockerfile/build.sh contract and the 24x7/sanitiser facts already in the description, so it could be tightened. Not a 1 because it avoids explaining basic concepts and uses tables/code blocks effectively.

2 / 3

Actionability

Provides concrete executable commands—'infra/helper.py build_image', 'build_fuzzers --sanitizer address', 'check_build', 'reproduce <project-name> fuzz_target_1 <crash-file>'—plus a fully worked example and a complete build.sh/project.yaml contract in the reference, making guidance copy-paste ready.

3 / 3

Workflow Clarity

The 'How to use' and 'Running' sections give a clear numbered sequence with an explicit local validation checkpoint (build_image -> build_fuzzers -> check_build) before the PR, and the 'Parsing results' loop covers reproduce -> confirm -> patch -> close within the 90-day deadline.

3 / 3

Progressive Disclosure

SKILL.md is an overview that offloads the full field-by-field contract to a single well-signaled one-level-deep reference (references/project-contract.md, which exists and is complete), and lists composition/sibling relationships clearly; navigation is easy and references do not nest.

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.

The description is specific, trigger-rich, and clearly answers both what and when with an explicit 'Use to...' clause in third person. It is dense but every clause earns its place and it distinguishes itself from sibling fuzzing skills.

DimensionReasoningScore

Specificity

Names multiple concrete actions—'Author and submit a project', the 'project.yaml + Dockerfile + build.sh contract', 'seed-corpus + dictionary submission', and 'issues filed in Monorail with 90-day deadline'—matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Clearly answers what (author/submit an OSS-Fuzz project with the stated contract and conventions) and when via the explicit 'Use to offload long-running fuzz campaigns to dedicated infrastructure rather than self-hosting' trigger clause.

3 / 3

Trigger Term Quality

Includes natural terms users would say—'fuzz', 'fuzzing', 'libFuzzer / AFL++ / Honggfuzz', 'OSS-Fuzz', 'seed corpus', 'dictionary'—with strong coverage of common variations.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (Google OSS-Fuzz project submission) with distinct triggers unlikely to overlap with sibling fuzzer skills; third-person voice is used throughout.

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