Conciseness

The body is dense and assumes competence: terse rules ("No Exploit = No Report"), a compact coverage matrix, and one-line phases with no conceptual padding. Not 5 because the References section re-lists compliance-mapping.md and continuous-pentest.md already linked inline, and some matrix cells restate vulnerability classes Claude already knows (e.g., "SQLi, CMDi, NoSQLi, LDAPi").

Actionability

Concrete, specific guidance throughout: named tools ("npm audit, pip-audit, cargo audit"), platform-specific checks ("WebView loadUrl, JavaScript bridges", "debuggable=true, ATS exceptions"), and per-phase pointers to reference files verified to contain executable commands. Not 5 because the Post-Exploit phase ("Assess blast radius, lateral movement, privilege escalation") has no reference file and lacks the specific detail the other phases get.

Workflow Clarity

The 7-phase sequence is clearly ordered with per-phase outputs, and the Always-Apply rules act as global checkpoints ("Every finding requires reproducible PoC", "Confirm authorization before Phase 1"). Not 5 because validation is imposed as global rules rather than inline phase gates with feedback loops, and the phase numbering is inconsistent: the References section labels recon/exploit/report as Phases 1/4/6 while the workflow numbers them 2/5/7 (reference files also use Phase 0 for scoping).

Progressive Disclosure

SKILL.md is a lean overview (workflow + matrix) with all detail split into seven real, one-level-deep reference files (verified on disk, 2.7-4.9 KB each, no nested cross-references), each clearly signaled with a descriptive label in both the workflow and a References index. This matches the anchor-5 structure.

Specificity

"Provides attack taxonomy, exploit techniques per vulnerability class, and platform-specific test matrices" names the domain (backend, frontend, mobile) and lists several concrete deliverables. Not 5 because the actions are content descriptions ("provides X") rather than operational verbs, and coverage stays at the methodology level; not 3 because three-plus specific capabilities are explicitly enumerated.

Completeness

The description explicitly answers both questions: what ("PTES-aligned penetration testing methodology... attack taxonomy, exploit techniques per vulnerability class, and platform-specific test matrices") and when ("Use when executing pentest workflow, planning security assessments, mapping attack surfaces, or building threat models") with concrete trigger phrases. This directly matches the anchor-5 example pattern.

Trigger Term Quality

"Use when executing pentest workflow, planning security assessments, mapping attack surfaces, or building threat models" contains natural phrases users would say (pentest, security assessment, attack surface, threat model). Not 5 because common synonyms like "red team", "ethical hacking", or "vulnerability assessment" are absent from the description itself; not 3 because coverage goes well beyond one or two generic keywords.

Distinctiveness Conflict Risk

"PTES-aligned" and "pentest workflow" carve out a clear niche with distinct triggers. Not 5 because "planning security assessments" and "building threat models" are broad enough to overlap with closely related security skills (the body itself references sibling skills like common-security-audit); not 3 because the PTES/pentest framing is far more specific than generic overlap anchors.