703-technologies-fuzzing-testing

Use when you need to add or review fuzz testing for Java APIs with CATS — including contract-driven negative testing, malformed payload validation, boundary input exploration, CI integration, reproducible failures, and local execution guidance. This should trigger for requests such as Add fuzz testing to a Java project; Use CATS for API negative testing; Review CI quality gates for API contract robustness; Improve boundary and malformed input test coverage; Run CATS fuzz tests against an OpenAPI contract. Part of Plinth Toolkit

Quality

77%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/703-technologies-fuzzing-testing/SKILL.md

Quality

Content

67%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-structured, concise overview with a clear workflow and validation guardrails, appropriate for a reference-backed skill. Its main weakness is actionability: the actual CATS execution is delegated to bundle files without an inline executable example.

Suggestions

Add a short inline CATS invocation example (e.g. the baseline `java -jar cats/cats.jar --contract openapi.yaml --server http://localhost:8080` or a one-line call to scripts/run-cats-fuzz.sh) so the core action is executable without opening the reference.

Explicitly link the bundle files in the body (e.g. 'See [scripts/run-cats-fuzz.sh](scripts/run-cats-fuzz.sh) and [assets/cats.dockerfile](assets/cats.dockerfile)') to make navigation of the script and Dockerfile one level deep.

Remove or condense the 'When to use this skill' section since its trigger phrases already appear in the description, avoiding duplication.

Dimension	Reasoning	Score
Conciseness	The body is lean with bullet lists, constraints, and a short workflow, and does not over-explain concepts Claude already knows; however the 'When to use this skill' section duplicates trigger phrases already present in the description, a minor instance of padding that keeps it just below 5.	4 / 5
Actionability	Concrete commands exist for build verification ('./mvnw compile', 'mvn clean verify') and real file references are named, but the core action — running CATS — is deferred to the reference and script with no inline executable CATS command, leaving the workflow steps as high-level hints ('Implement or refactor artifacts following the reference patterns').	3 / 5
Workflow Clarity	A clear 4-step sequence (read reference, gather scope, apply changes, verify and report) is present alongside explicit validation checkpoints in the Constraints section (MANDATORY compile-before, SAFETY stop-on-failure, VERIFY after), so the destructive/batch cap does not apply; checkpoints live in a separate block rather than inline in the steps, a minor gap.	4 / 5
Progressive Disclosure	The body is a concise overview with a clearly signaled one-level-deep reference link (references/703-technologies-fuzzing-testing.md, verified present); the bundle files scripts/run-cats-fuzz.sh and assets/cats.dockerfile exist but are not explicitly linked or navigated from the body, a minor organization gap.	4 / 5
	Total	15 / 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, specific description with clear what/when structure and natural trigger phrases. The only flaw is second-person voice ('you need to'), which costs it one specificity point per the rubric's voice guideline.

Suggestions

Rewrite in third person to avoid the second-person penalty, e.g. 'Use when adding or reviewing fuzz testing for Java APIs with CATS...' rather than 'Use when you need to...'.

Add a few synonyms or file extensions (e.g. 'OpenAPI spec', '.yaml/.yml contract', 'Swagger') to push trigger-term coverage to 5.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions ('contract-driven negative testing, malformed payload validation, boundary input exploration, CI integration, reproducible failures, and local execution guidance') which is comprehensive, but the description uses second person ('Use when you need to'), which per the rubric guideline reduces the specificity score by one from 5.	4 / 5
Completeness	Explicitly answers both 'what' (add or review fuzz testing for Java APIs with CATS, with a list of capabilities) and 'when' ('Use when you need to...', 'This should trigger for requests such as...') with concrete trigger phrases, matching the anchor-5 example.	5 / 5
Trigger Term Quality	Provides strong natural trigger phrases ('Add fuzz testing to a Java project', 'Use CATS for API negative testing', 'Run CATS fuzz tests against an OpenAPI contract') users would actually say, but lacks synonyms and file extensions (e.g. .yaml, OpenAPI spec) that would push it to 5.	4 / 5
Distinctiveness Conflict Risk	Occupies a clear niche — Java API fuzz testing with the specific CATS tool — with distinct triggers and minimal overlap risk with other skills.	5 / 5
	Total	18 / 20 Passed

Validation

100%

Warnings & errors only

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.

Repository: jabrena/plinth
Path: skills/703-technologies-fuzzing-testing/SKILL.md
Commit: 77b8825

Reviewed: about 23 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.