Lists multiple specific concrete actions: 'Build and configure', 'redirectors', 'HTTPS listeners', 'multi-operator support'. These are concrete, actionable capabilities within a well-defined domain.

The 'what' is well-covered (build/configure Sliver C2 with redirectors, HTTPS listeners, multi-operator support), but there is no explicit 'Use when...' clause. The phrase 'for authorized red team engagements' hints at context but doesn't serve as an explicit trigger guidance, capping this at 2 per the rubric.

Includes strong natural keywords a red teamer would use: 'Sliver C2', 'command-and-control', 'C2 framework', 'redirectors', 'HTTPS listeners', 'red team', 'BishopFox'. These are terms practitioners naturally use when seeking this capability.

Highly distinctive due to the specific tool name (BishopFox's Sliver C2), specific infrastructure components (redirectors, HTTPS listeners), and specific use case (red team engagements). Very unlikely to conflict with other skills.

The content is heavily padded with sections Claude already knows (overview explaining what Sliver is, MITRE ATT&CK mappings, detection signatures table, generic 'When to Use' and 'Prerequisites' sections). The 'When to Use' section is particularly egregious with vague boilerplate. The overview paragraph explains basic concepts like what Go is and what C2 channels are. Significant token waste throughout.

The skill provides real commands and configuration snippets (NGINX config, iptables rules, Sliver CLI commands) which are concrete and mostly executable. However, some commands may not be fully accurate (e.g., `new-operator` syntax, `generate beacon` flag combinations), and the domain fronting setup in Phase 3 step 4 is left as a vague 'optionally set up Cloudflare' without any concrete steps. The post-exploitation section is decent but reads more like a reference card than actionable workflow guidance.

The five-phase workflow is clearly sequenced and logically ordered. However, there are no explicit validation checkpoints between phases (e.g., verify the listener is active before generating implants, test redirector connectivity before deploying implants). The validation criteria checklist at the end is a post-hoc checklist rather than integrated feedback loops. For an operation involving infrastructure deployment with multiple failure points, the lack of inline verification steps is a notable gap.

The content is a monolithic wall of text with no references to external files, no layered structure, and no separation of concerns. The detection signatures table, tools table, MITRE mappings, and detailed post-exploitation commands could all be in separate reference files. Everything is inlined into a single long document with no bundle files to support it.