Content
80%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A lean, highly actionable command reference: nearly every section is copy-runnable ffuf/curl code with no wasted tokens. The weaknesses are the missing validation layer for batch fuzzing operations and a few executable-detail gaps (the <default_size> placeholder and the prose-only API key pattern list).
Suggestions
Add validation steps after each fuzzing phase, e.g. manually confirm discovered endpoints/parameters, filter ffuf false positives by -fs/-mr, and re-test parameters with different values to distinguish real ones from noise.
Replace the "-fs <default_size>" placeholder with a concrete calibration step, e.g. capture the default response size first (curl the unparameterized page and use its byte count) or use ffuf's -fs auto-filtering workflow.
Turn the "API Key/Token Patterns" prose list into a command, e.g. a grep/regex one-liner for api_key|apiKey|access_token|bearer|jwt over captured responses, and fix the inconsistent wordlist paths (api-wordlist.txt vs /usr/share/wordlists/...).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and command-first with zero concept explanation: the only prose is the scoping sentence "This sub-skill covers everything between 'the directory tree is mapped' and 'I know what to fuzz'" and terse comments like "# Common API paths", all of which earn their place. Not 4 because there is no over-explanation anywhere that could be trimmed. | 5 / 5 |
Actionability | Concrete executable commands dominate (ffuf with -mc/-fs flags, curl loops for swagger docs, a GraphQL introspection POST with a real query body). Not 5 because "-fs <default_size>" is an undefined placeholder with no calibration step, wordlist paths are inconsistent ("api-wordlist.txt" vs "/usr/share/wordlists/params.txt"), and the "API Key/Token Patterns" section is a prose list ("Look for in responses: api_key, apiKey...") with no command; not 3 because the commands are genuinely executable rather than pseudocode. | 4 / 5 |
Workflow Clarity | Numbered sections give a rough sequence ("## 1. API Endpoint Enumeration" then "## 2. Parameter Discovery") but the workflow ends at running the tools with no validation checkpoints. Fuzzing is a batch operation (thousands of requests via ffuf), and the batch-operation cap applies: there is no false-positive filtering, no confirmation of discovered endpoints, and no verification of parameter findings, capping workflow clarity at 3 regardless of the simple-skill exception. | 3 / 5 |
Progressive Disclosure | The body is a compact ~55 lines organized into clearly numbered sections and subsections, with everything appropriately inline and nothing that belongs in a separate file. No bundle files exist and none are needed, so per the simple-skill guidance well-organized sections alone merit the top score. | 5 / 5 |
Total | 17 / 20 Passed |