Conciseness

The body is commands-plus-one-line-comments throughout ("kubectl auth can-i --list --all-namespaces # cluster-wide (often forbidden — that's a signal too)") and never explains concepts Claude already knows like what RBAC or a ServiceAccount is. Every section — including OPSEC notes on audit-log visibility — adds non-obvious signal, matching the 'lean and efficient; every token earns its place' anchor.

Actionability

Nearly all guidance is copy-paste executable: full kubectl command sequences, a complete privileged-pod YAML manifest, a full ClusterRole manifest, and jq filters. It falls short of a 5 because several examples carry unresolved placeholders the operator must substitute ("privileged-pod-name", "$NODE", "POD_NS/POD_NAME", "YOUR_SA_NAME", "$(...)-token-XXXXX"), so the common cases aren't fully turnkey.

Workflow Clarity

The sequence is explicit (Phase 1 enumerate → Phase 2 escalation paths → Phase 3 persistence) with per-path precondition checks ("kubectl auth can-i escalate clusterroles / # If 'yes':") and a genuine feedback loop ("If PSP / Pod Security Admission blocks `privileged: true`, downgrade gradually"). Not a 5 because post-escalation verification ("kubectl --token=... auth can-i '*' '*' --all-namespaces") appears only on some paths, not as a consistent checkpoint after each technique.

Progressive Disclosure

A single-file skill with no bundle files (no references/, scripts/, or assets/ directories) and clear, well-labeled section headers; content is appropriately sized for one file. It doesn't reach 5 because the only cross-reference ("see k8s-pod-escape skill") points to a skill outside this bundle with no path or link, and the external References section (BadPods, DEFCON talk, KubiScan) is plain text rather than signaled navigation.

Specificity

The description enumerates multiple concrete capabilities: "ClusterRole/Role enumeration via `kubectl auth can-i --list`", "abuse of pods/exec, pods/portforward, secrets get, escalate verb, bind verb, impersonate verb, system:masters group abuse, ServiceAccount token theft and reuse". This is comprehensive coverage of the RBAC escalation path space, matching the 'multiple specific concrete actions; comprehensive coverage' anchor rather than the 4 anchor's 'minor gaps'.

Completeness

The "what" is clear and concrete, but there is no "Use when…" clause or equivalent explicit trigger guidance anywhere in the description — the "when" is entirely absent rather than merely weakly implied, which the judging guidelines cap at 3. It is not a 2 because the "what" half is fully present and specific, and not a 4 because a weakly-implied "when" would still be required.

Trigger Term Quality

Good natural keyword coverage — "Kubernetes", "RBAC", "privilege escalation", "secrets", "ServiceAccount", "token theft" — terms a user would plausibly say. It stops short of the 5 anchor because common synonyms and variations are missing from the description itself: no "k8s" abbreviation, no "cluster-admin", no "service account" as two words (these appear only in the separate metadata.when_to_use field, not the description).

Distinctiveness Conflict Risk

The description carves out a clear niche — RBAC-specific privilege escalation with distinct verbs ("escalate verb, bind verb, impersonate verb") — that would not naturally trigger general Kubernetes, container-escape, or non-K8s skills. Minimal conflict risk, matching the 5 anchor; the 4 anchor's 'minor overlap with closely related skills' doesn't apply since the triggers are uniquely RBAC-specific.