CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/restler-fuzzing

Use when a stateful REST API (resources created, read, changed and deleted in sequence) needs fuzzing that finds multi-step bugs stateless fuzzers miss. Runs Microsoft RESTler from an OpenAPI spec (compile, test, fuzz-lean, fuzz) and reports 5xx errors, resource leaks and hierarchy violations.

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

92%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 high-quality, operations-ready skill body: every stage of the RESTler workflow has copy-paste commands, validation checkpoints with stop conditions are explicit, and bulky CI/output-tree detail is properly offloaded to a single well-signaled reference file. The only meaningful improvement is trimming repeated 'Per restler-readme' citations and the Overview/When-to-use overlap. Safety-relevant guidance (target staging, not production; replay-confirm before filing tickets) is present and concrete.

DimensionReasoningScore

Conciseness

The body is efficient - tables for bug categories, cadences and anti-patterns; no explanations of concepts Claude already knows - but there is trimmable redundancy: "Per [restler-readme][readme]" is repeated about five times including a standalone "(Per [restler-readme][readme].)" line, and the Overview and When-to-use sections overlap on the stateful/stateless distinction. This matches level 4 (efficient with minor instances that could be trimmed) rather than level 5, where every token earns its place.

4 / 5

Actionability

Fully executable guidance throughout: complete build and Docker install commands, all four restler stage invocations with full flags, a copy-paste auth flow (curl + jq into an auth dictionary), the replay command for triage, and a concrete bug-count CI gate. The only placeholders (<api-host>, $TOKEN) are unavoidable target-specific values, matching the level-5 anchor.

5 / 5

Workflow Clarity

The four-stage workflow is clearly sequenced with an explicit validation gate and feedback loop - "If endpoint coverage is below the team's threshold (often 80%+), stop and amend the dictionary or grammar before continuing" - reinforced by the anti-patterns checklist ("Always run Test first; check coverage before fuzz-lean") and a staged per-bug triage sequence. This matches level 5 (explicit validation steps, feedback loops, checklist) rather than level 4, which allows minor validation gaps that are not present here.

5 / 5

Progressive Disclosure

SKILL.md is a well-organized overview that offloads the exhaustive material - the full results directory layout and the complete GitHub Actions YAML - to references/triage-and-ci.md, which exists in the bundle and is one level deep with no further nesting. Both in-body references are clearly signaled with a description of what the file contains, matching the level-5 anchor.

5 / 5

Total

19

/

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 strong description that pairs an explicit, concrete 'Use when' trigger (stateful REST API needing multi-step bug discovery) with a specific capability statement (four RESTler stages from an OpenAPI spec, three named bug categories). The stateful-vs-stateless contrast sharply reduces conflict risk with a companion stateless-fuzzing skill. The only weakness is slightly thin synonym coverage for trigger terms.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions - "Runs Microsoft RESTler from an OpenAPI spec (compile, test, fuzz-lean, fuzz)" and "reports 5xx errors, resource leaks and hierarchy violations" - covering both the operation and its outputs comprehensively. It clearly matches the level-5 anchor (multiple specific concrete actions, comprehensive coverage) rather than level 4, since no meaningful capability is left unnamed at the description level.

5 / 5

Completeness

It explicitly answers both questions: "Use when a stateful REST API (resources created, read, changed and deleted in sequence) needs fuzzing that finds multi-step bugs stateless fuzzers miss" is a concrete when-clause, and "Runs Microsoft RESTler from an OpenAPI spec... and reports 5xx errors, resource leaks and hierarchy violations" is a clear what. This matches the level-5 anchor with concrete trigger phrases on both halves.

5 / 5

Trigger Term Quality

Natural phrases a user would say are present - "stateful REST API", "fuzzing", "multi-step bugs", "OpenAPI spec" - giving good keyword coverage. It falls short of level 5 because common synonyms and variations (e.g. "Swagger", "API security testing", "endpoint testing") are missing, but it exceeds level 3 since the core natural terms users would actually utter are all there.

4 / 5

Distinctiveness Conflict Risk

It carves out a clear niche ("stateful REST API") and explicitly contrasts with the adjacent skill category ("multi-step bugs stateless fuzzers miss"), minimizing wrong-skill triggers. This matches the level-5 anchor (clear niche with distinct triggers, minimal conflict risk) and is more disambiguated than the level-4 'minor overlap' example.

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

On this page