Content
83%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.
A lean, highly actionable playbook: real commands for every identification, request, and cracking path, plus genuinely non-obvious empirical content (password heuristics, OPSEC events, SPN impact table). The main gap is the complete absence of validation checkpoints across a batch workflow — nothing confirms ticket capture, crack success, or credential validity before the promote step.
Suggestions
Add validation checkpoints between steps: verify /tmp/kerb.hashes is non-empty before hashcat, check hashcat output for cracked pot lines before promotion, and validate the credential authenticates (e.g. a single smbexec/ldap bind test) before kg_add_node — with an error-recovery path (re-run with different rules/wordlist if no cracks).
Add a verification step after identification that the collected SPN list is complete (coverage confirmation) before batch-requesting tickets, since the skill itself warns the OPSEC risk of requesting all SPNs at once but leaves the throttle wrapper undescribed.
Move the common-services table and password heuristics into a reference file (e.g. references/ targets and heuristics) to slim the main body below the simple-skill threshold, keeping SKILL.md as a lean overview.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section carries operation-specific knowledge Claude cannot reliably improvise: the ldapsearch filter, hashcat modes 13100/19700, the '$krb5tgs$23$' vs '$krb5tgs$18$' hash-format tell, empirically-derived password heuristics ('ServiceName + season + year', 'SQLSvc2024!'), 4769-event OPSEC signals, and the SPN-to-impact table. Nothing explains what Kerberos or hashcat is; it fully matches anchor 5's 'lean and efficient; assumes Claude's competence; every token earns its place'. | 5 / 5 |
Actionability | Commands are copy-paste ready and cover the common cases: a complete ldapsearch query with the exact UAC/bitness filter and attributes, 'GetUserSPNs.py DOM/USER:'PASS' -dc-ip DC_IP -request -outputfile /tmp/kerb.hashes', 'Rubeus.exe kerberoast /outfile:... /nowrap', and three hashcat invocations covering RC4 (mode 13100), AES256 (19700), and a combinator attack for pattern-based service passwords. This matches anchor 5; the only substitutions needed (DC_IP, USER, PASS) are engagement-specific values, and the kg_add_node/kg_add_edge promotion template is a concrete API shape rather than vague direction. | 5 / 5 |
Workflow Clarity | The five-step sequence (identify → request → crack → promote → post-crack) is clearly ordered, but there are no validation checkpoints anywhere: no verify that /tmp/kerb.hashes is non-empty before cracking, no check of hashcat exit status / cracked-vs-uncovered outcomes, and no confirmation that the cracked credential actually authenticates before promoting it into the knowledge graph. Kerberoasting is a batch operation (requesting tickets for all roastable SPNs, cracking a hash file), and the rubric explicitly caps workflow_clarity at 3 for batch operations without validation feedback loops — this precludes anchor 4 despite the strong sequence. | 3 / 5 |
Progressive Disclosure | The body (~89 lines) is a single well-organized file with clear section headers and no bundle files exist to reference, so navigation risk is low. It falls short of anchor 5 (which the under-50-line simple-skill exception would otherwise grant): the SPN-to-impact table, password-pattern heuristics, and CVSS severity guidance are reference-style content that could live in a separate file, matching anchor 4's 'good structure; most content appropriately placed; minor organization gaps'. | 4 / 5 |
Total | 17 / 20 Passed |