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.
A highly actionable, domain-expert body with executable code and well-sequenced procedures for both profile formats. Its main weaknesses are a monolithic structure that inlines reference-grade material (huge-file parsing, category tables) and noticeable redundancy between the two parallel procedures.
Suggestions
Move the 'Handling Huge Files' Buffer-parsing code and the trace phase/category tables into separate reference files (e.g. references/huge-files.md, references/trace-format.md) and link them from a lean SKILL.md overview, reducing the main body to the detection, key concepts, and core procedures.
Deduplicate the size-check and reformat steps shared by Part 1 and Part 2 (a single 'Parsing' section covering both formats), and consolidate the repeated '--max-old-space-size=16384' advice into one place.
Remove or bundle the dangling 'parseSnapshot.ts' reference, and make the Part 2 'Build Data Structures' snippet consistent with the size-guarded parsing pattern (use the imported 'readFileSync' rather than 'fs.readFileSync').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient and rich in genuinely non-obvious detail (format internals, trace category tables, the ~512MB V8 string limit workaround), but there is clear redundancy: the size-check and reformat steps are repeated nearly verbatim in Part 1 and Part 2, and 'node --max-old-space-size=16384' appears three times. Matches the 'mostly efficient but could be tightened' anchor; not a 4 because the duplication is more than minor. | 3 / 5 |
Actionability | Concrete, executable Node.js code covers parsing, node/parent map construction, stack walking, event filtering, embedded profile reconstruction, and Buffer-based huge-file extraction. Not a 5: the 'Handling Huge Files' section references 'parseSnapshot.ts' which is not part of this skill's bundle, and the Part 2 'Build Data Structures' snippet re-parses without the size guard and mixes 'fs.readFileSync' with the 'import { readFileSync }' idiom used elsewhere. | 4 / 5 |
Workflow Clarity | Both file types have clear numbered procedures with an upfront file-size checkpoint and a file-type detection section, and each procedure ends with an explicit report format. Not a 5: there are no explicit error-recovery/checkpoint loops (e.g. what to do when a marker function never appears or a key is missing from the buffer), so minor validation gaps remain. | 4 / 5 |
Progressive Disclosure | The ~510-line monolithic body inlines substantial content that belongs in separate reference files — notably the ~150-line Buffer-based parsing section and the exhaustive phase/category/process tables — with no bundle files present. In-file navigation via headers and tables is good, but content that should be split is inline, matching the anchor 3 example. | 3 / 5 |
Total | 14 / 20 Passed |