Content
63%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 is a well-organized, source-anchored adversary-emulation profile with concrete TTP-to-capability mapping and explicit safety controls for destructive ops. Its main weaknesses are background prose that pads the token budget and a monolithic structure that could benefit from splitting detailed reference material into bundle files.
Suggestions
Trim the opening paragraph and 'Attribution & motivation' background re-explanation to the non-obvious facts only (RGB attribution, DOJ/Park Jin Hyok anchor), cutting prose Claude already knows.
Move the full TTP-by-tactic catalog, signature-tooling list, and campaign timeline into separate reference files (e.g., references/ttps.md, references/campaigns.md) and link to them from SKILL.md to improve progressive disclosure.
Add a short numbered 'emulation workflow' checklist at the top of the emulation-guidance section (plan scope → initial access → C2 → persist → … → validate detections) with an explicit validation step to push workflow clarity toward 5.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is a dense factual reference (TTP IDs, malware S-numbers, sourced campaigns) that mostly earns its tokens, but the opening paragraph and 'Attribution & motivation' section re-explain background history Claude largely already knows and could be tightened, matching 'mostly efficient but includes some unnecessary explanation'. | 3 / 5 |
Actionability | The emulation-guidance section maps each TTP to concrete capabilities and named sibling skills ('deploy Sliver with HTTPS/mTLS profiles, jitter, fallback listeners', 'defense-evasion skill', 'AD and lateral-movement skills'), and detection guidance cites specific telemetry; minor gaps keep it just below fully executable. | 4 / 5 |
Workflow Clarity | Emulation guidance is sequenced as a clear behavior chain (initial access → trojanized app → C2 → execution/persistence → evasion → creds → discovery/lateral → collection/exfil → impact) with explicit safety checkpoints for destructive ops ('do not run real wipers', 'controlled, reversible marker'), satisfying the destructive-operation validation requirement; it is a mapping rather than a strict feedback-loop procedure, so not a 5. | 4 / 5 |
Progressive Disclosure | Sections are well-headered and self-contained with no nested references, but the file is a monolithic ~135-line document whose detailed TTP-by-tactic catalog, signature-tooling list, and campaign timeline could reasonably live in separate reference files; with no bundle files present this matches 'some structure but content that should be separate is inline'. | 3 / 5 |
Total | 14 / 20 Passed |