Content
82%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-crafted, information-dense reference: real exploit post-mortems distilled into pattern-level lessons, a concrete audit checklist, and runnable tooling commands, with explicit OPSEC gating for a destructive-capability domain. The remaining gaps are small — incomplete code snippets, a non-linked references section, and no explicit end-to-end audit sequence with finding-verification steps.
Suggestions
Complete the Solidity snippets (replace ecdsa/hash ellipses with compilable vulnerable-vs-fixed pairs) or explicitly label them as illustrative vulnerability patterns so the actionability gap is closed by design.
Add URLs (or local reference files) to the References section — 'Rekt.news', 'Trail of Bits Cross-Chain Bridge Architecture' are currently unresolvable names.
Promote the checklist into an explicit ordered workflow (1. identify bridge type from the taxonomy, 2. run the 8 checklist items, 3. verify each suspicion on a private fork with the Foundry/Echidna tooling) with a confirm-findings step.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and dense: the framing is one distilled line ('Bridges hold large pooled assets and execute messages from a separate trust layer. Architecturally fragile.'), each attack class is 2-3 sentences plus minimal code, and the checklist items are single lines. It never explains concepts Claude already knows, and the historical dates/dollar figures are stable facts rather than stale-prone version info — matching the 'every token earns its place' anchor with nothing to trim. | 5 / 5 |
Actionability | Concrete, executable commands are present (forge test --fork-url $RPC --match-contract Bridge --fork-block-number 17000000, slither <project>, echidna-test test/Bridge.t.sol --config echidna.yaml) alongside an 8-item checklist of specific verifiable checks ('nonce-used mapping written BEFORE external token call'). However, the Solidity snippets contain ellipses (ecrecover(hash, ...) == validator) making them illustrative patterns rather than copy-paste-ready code, and the References section lacks URLs — minor gaps that keep it at 'mostly executable' rather than fully executable. | 4 / 5 |
Workflow Clarity | The document reads as a coherent methodology (taxonomy → attack classes → audit checklist → tooling → OPSEC/disclosure) and explicitly gates the destructive domain ('Never test against live bridges without explicit ownership/written authorization'; 'read the Immunefi scope, then test on a private fork'), so the destructive-operation cap does not apply. Minor gaps remain: there is no explicit ordered audit workflow (e.g., fork → run checklist → verify with tooling) and no feedback loop for confirming a suspected finding — matching 'clear sequence with most checkpoints present; minor validation gaps' rather than the explicit-validation anchor. | 4 / 5 |
Progressive Disclosure | The skill is a single self-contained ~115-line file with well-organized, clearly headed sections and no bundle files, so all content is appropriately inlined. The under-50-lines full-credit exception does not apply, and the References section lists external resources by name ('Rekt.news', 'Trail of Bits deep dive') without URLs or file paths, which — along with the moderate length — constitutes the minor organization gaps of the 'good structure' anchor rather than the clear-navigable-references anchor. | 4 / 5 |
Total | 17 / 20 Passed |