Content
50%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 knowledge reference with genuinely useful thresholds, tables, and an excellent output-format template, but it reads as a domain explainer rather than an operational skill: the code is non-executable pseudocode, data sources are listed without any access instructions, and there is no sequenced analysis workflow or validation steps. Most dimensions sit at the middle anchor with clear, specific paths to improvement.
Suggestions
Replace the pseudocode with executable code: give at least one working data fetch (e.g., a concrete CoinGlass or OKX API endpoint with a code snippet) and implement identify_liquidation_clusters() with defined inputs instead of undefined helper functions.
Add an explicit numbered workflow section (gather liquidation/OI data → identify clusters → assess magnet asymmetry and cascade risk → check post-liquidation S/R → emit the output format) so the skill instructs rather than only explains.
Trim content Claude already knows — collapse the leverage/distance table and the liquidation-mechanics derivation to one or two lines — and move reference material (exchange comparison, metrics tables) into a references/ file to shorten SKILL.md toward an overview.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~280-line body is well-sectioned but includes material Claude largely already knows: basic liquidation mechanics with entry-price formulas ('long_liquidation_price = entry_price * (1 - 1/leverage + maintenance_margin)') and a leverage-vs-liquidation-distance table (10x → ~10% drop) that is just 1/leverage restated six times. The 'magnets' concept is also explained twice (Overview and Key principles). It is mostly efficient with useful thresholds and tables, so not below the midpoint, but clearly could be tightened toward anchor 4. | 3 / 5 |
Actionability | Concrete guidance exists (threshold tables like '> $500M = extreme', the full output-format template, and signal functions with explicit thresholds such as 'if above_magnitude > below_magnitude * 2'), but the core code is pseudocode: identify_liquidation_clusters() calls undefined helpers (estimate_long_liq_at_price, estimate_short_liq_at_price) and undefined globals (price_range, significance_threshold), and the Data Sources table names CoinGlass/Laevitas/OKX API without any endpoint, command, or usage example. This matches anchor 3 — 'pseudocode instead of executable code; missing key details' — rather than 4's mostly-executable standard. | 3 / 5 |
Workflow Clarity | The sections imply a rough sequence (mechanics → heatmap reading → cluster identification → signals → metrics → output format) and the cascade guidance gives before/during/after actions, but there is no explicit step-by-step procedure for conducting an analysis (e.g., fetch data → identify clusters → assess cascade risk → produce output) and no validation checkpoints on estimated data. This is the 'sequence present but checkpoints missing or implicit' anchor, not 4's 'clear sequence with most checkpoints'. | 3 / 5 |
Progressive Disclosure | The single 281-line SKILL.md has clear section headers but no bundle files and no external references, while substantial reference material (exchange liquidation-engine comparison, metrics tables, signal implementations, data-source details) is inlined and would fit separate reference files. At well over the 50-line simple-skill threshold, this lands on anchor 3: 'some structure but could be better organized; content that should be separate is inline' rather than 4's mostly-appropriate placement. | 3 / 5 |
Total | 12 / 20 Passed |