Conciseness

The body is dense with domain-specific, non-redundant operational content — tool commands, payloads, verdict rules, evidence-pairing requirements — and mostly avoids explaining concepts Claude already knows. It sits at 'efficient; minor instances of over-explanation that could be trimmed': the combined-mode section and output-format template are long, and a few editorial asides ("You're in", "didn't get the memo") could be cut. It is not score 3 because nearly every line carries actionable testing or recording guidance rather than padding.

Actionability

Guidance is fully executable throughout: concrete commands ("curl -I -H \"Origin: https://evil.com\"", "testssl.sh https://target", "sqlmap ... --risk=1 --level=1"), specific payloads ("' OR 1=1 --", "'; SELECT pg_sleep(5)--", "{{7*7}}"), a step-by-step IDOR procedure (sign in as A, replay as B, expect 403/404), and runnable validation commands ("node references/validate-findings.mjs findings.json"). Specific examples cover the common cases; nothing is pseudocode.

Workflow Clarity

The sequence is explicit with validation checkpoints and feedback loops: Authorization Check gates everything, nine ordered methodology phases each produce evidence, findings are run through a refutation pass ("Run every candidate through the refutation pass ... before it is confirmed"), and the record workflow is "Write findings.json sorted by fingerprint, then validate and fix until it passes" — a validate → fix → re-validate loop with exit-code semantics documented in the referenced guide. This matches the score-5 anchor including error-recovery feedback.

Progressive Disclosure

References are well-signaled, one level deep, and all real: findings-format.md, verification.md, severity-calibration.md, validate-findings.mjs, and to-sarif.mjs are each linked inline at the point of need and exist in references/. It is not score 5 because the nine-phase methodology checklist (~200 lines) is fully inlined in SKILL.md where a WSTG phase-details reference could carry some of it, and cross-skill pointers (business-logic-testing, owasp-audit, recon) are named but not linked paths — good structure with minor organization gaps.

Specificity

The description lists multiple concrete capabilities specific to the domain: "auth bypass, IDOR, session handling, business-logic flaws, parameter tampering, Burp Suite / OWASP ZAP workflows" — comprehensive coverage of what the skill does. It fits the score-5 anchor (multiple specific concrete actions) and not score 4, since there are no meaningful gaps in capability coverage for the stated domain.

Completeness

Both halves are explicit: the 'what' ("Perform black-box / grey-box web application penetration testing on an authorized target..." with enumerated capability areas) and the 'when' ("Use when the user mentions... or has explicit authorization to test a live web application"). This matches the score-5 anchor exactly; it is not score 4 because the 'when' clause is already fully explicit with concrete trigger phrases.

Trigger Term Quality

Trigger phrases are comprehensive and natural: "'web pentest,' 'web application penetration test,' 'pentesting,' 'bug bounty,' 'Burp Suite,' 'ZAP,' 'OWASP testing,' 'authentication testing,' 'session testing,' 'authorization testing,' 'web vulnerability testing'" plus a situational trigger ("has explicit authorization to test a live web application"). This covers synonyms and tool names users would actually say; nothing common is missing.

Distinctiveness Conflict Risk

The live black-box/grey-box web app testing niche with named tools (Burp, ZAP) is clear and mostly distinct from source-audit skills. Minor overlap risk remains with closely related security skills: broad triggers like "'pentesting,'" "'web vulnerability testing,'" or "'authentication testing'" could also fire for adjacent audit skills, so it fits 'mostly distinct; minor overlap risk' rather than the fully distinct score-5 anchor.