Content
71%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 well-structured, technically deep playbook with runnable scapy code for every attack phase, explicit safety gating and evidence requirements for destructive operations. Its weaknesses are moderate: everything is monolithically inlined in SKILL.md instead of split into scripts/references files, a couple of code paths (DCP Get round-trip, Identify response parsing) are left incomplete, and safety warnings are repeated more than needed.
Suggestions
Move the DCP frame builders into a scripts/ file (e.g. scripts/dcp_frames.py) and keep SKILL.md as a phased overview with one-line invocations — this would cut the body roughly in half and fix progressive disclosure.
Complete the two unfinished code paths: a real DCP Identify-All response parser (walking DCP blocks to extract NameOfStation/IPSuite/VendorID) and an executed DCP Get round-trip with response parsing, since 'open in Wireshark' is not scripted guidance.
Consolidate the repeated authorization warnings into the single Phase 4 safety gate and reference it, trimming the duplicated disruption explanations to reduce token cost.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with protocol-specific detail Claude does not reliably know (DCP header layouts, service IDs, block option/suboption encodings, FrameID ranges), so most tokens earn their place. Not 5: there are minor trimmable instances — the authorization/safety warning is repeated four-plus times ('SAFETY FIRST', the Phase 4 'STOP' gate, repeated 'AUTHORIZED TESTING ONLY' comments, and the OPSEC reminder), and the opening deployment statistics ('virtually all post-2005 EU manufacturing') are background padding. Not 3: the verbosity is minor relative to the technical payload. | 4 / 5 |
Actionability | Concrete, mostly executable scapy builders for every phase plus tcpdump/wireshark commands with exact filters. Not 5: Phase 1's response parser is left as a 'simple heuristic parse' that defers to Wireshark, and Phase 2's DCP Get is entirely commented out with no response-parsing example — the reader never sees a completed Get round-trip. Not 3: the builders are real, runnable code with correct struct layouts, and the commented-out send lines for write-class operations are an intentional, justified safety gate. | 4 / 5 |
Workflow Clarity | Clear phased sequence (Prerequisites → Phase 1–5) with an L2-verification checkpoint ('tcpdump ... -c 20 / If frames appear: you are on the OT segment'), an explicit write-class safety gate before destructive operations, and validation guidance: ZFP two-method evidence, post-Set confirmation ('follow-up DCP Get confirming the new station name or IP'), and recording original values for restoration. Not 5: no explicit validate→fix→retry feedback loops, and Phase 1 device parsing falls back to 'open in Wireshark' rather than a scripted checkpoint. Not 3: destructive operations do have verification steps (BlockError=0x00 check plus follow-up Get), so the destructive-cap rule does not apply. | 4 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent) — all ~340 lines live in SKILL.md with good section headers, but content that clearly belongs in separate files is inlined: the full DCP frame builders (~150 lines of protocol code) belong in a scripts/ file, and the DCP option/suboption reference and OPSEC notes could be references/ files. This matches the anchor 'some structure but... content that should be separate is inline'. Not 4: for a skill this size, inlining everything is a real organization gap, not a minor one; not 2: headers and phase structure make it navigable. | 3 / 5 |
Total | 15 / 20 Passed |