Content
53%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.
The body delivers strong operational detail — real build commands, a complete teamserver profile, and a working redirector config — but the workflow lacks validation checkpoints, and progressive disclosure is the weakest area: the skill ships three reference files plus scripts and assets that are never linked from SKILL.md while their content is partially duplicated inline. Tightening the padded overview/when-to-use sections would also improve token efficiency.
Suggestions
Replace the inline MITRE ATT&CK table and the multi-week deployment timeline details with clearly signaled one-level-deep links to references/standards.md and references/workflows.md (e.g., '## MITRE ATT&CK mapping: See [standards.md](references/standards.md)'), and add a navigation section listing references/api-reference.md, scripts/, and assets/template.md so the existing bundle is discoverable.
Add validation checkpoints after each risky step: verify the build with a version/teamserver startup check, confirm the listener with a curl to the redirector URI expecting the C2 response vs. the 301 fallback, and include expected output for Step 4 like the one already present in Step 3.
Trim the Overview paragraph (Havoc/Cobalt Strike background Claude already knows) and the four generic 'When to Use' boilerplate bullets down to the one bullet that is specific to this skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The bulk is lean config and commands, but there is padding that could be trimmed: the Overview paragraph explains what Havoc is ('a modern, open-source post-exploitation command and control framework... similar to Cobalt Strike') which Claude already knows, the 'When to Use' section is four generic boilerplate bullets ('When establishing security controls aligned to compliance requirements'), and the MITRE ATT&CK table duplicates content already in references/standards.md. This fits 'Mostly efficient but includes some unnecessary explanation or could be tightened' — below level 4 because of the multiple padded sections, above level 2 because the operational steps themselves are not verbose. | 3 / 5 |
Actionability | The content is largely copy-paste ready: complete apt install and make build commands, a full havoc.yaotl profile, a complete nginx redirector config, and concrete Demon command examples. It falls short of the top anchor only in minor gaps — Step 5 is GUI instructions rendered as comments rather than executable commands, and some Demon examples carry unfilled placeholders ('token steal <PID>', 'TEAMSERVER_IP'). | 4 / 5 |
Workflow Clarity | Steps 1–6 give a clear install → configure → start → redirector → payload → post-exploitation sequence, but validation is mostly absent: only Step 3 shows expected output, and there are no checkpoints for verifying the build succeeded, the listener is reachable, or the redirector forwards correctly, nor any fix-and-retry guidance. This matches 'Steps listed but validation gaps; sequence present but checkpoints missing or implicit'. | 3 / 5 |
Progressive Disclosure | The bundle contains references/api-reference.md, references/standards.md, references/workflows.md, scripts/, and assets/, but the body never references any of them (grep confirms zero mentions of references/, scripts/, or assets/). Worse, the body inlines content that duplicates the bundle — the MITRE ATT&CK mapping table restates references/standards.md and the step-by-step deployment restates references/workflows.md — so content that clearly belongs in separate files is inlined and the existing references are undiscoverable. This fits 'Minimal structure; content that clearly belongs in separate files is inlined; or references are buried'; it does not reach level 3 because there are no signaled references at all, despite the body's own section headers being reasonable. | 2 / 5 |
Total | 12 / 20 Passed |