Content
77%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 dense, highly actionable operational script with excellent sequencing and genuine validation/feedback loops on its destructive operations, weakened by editorial padding and by monolithic inlining where reference files were clearly intended — including one reference to a file that is absent from the bundle.
Suggestions
Trim the design-history and rationale prose (remove-mode preamble, step 10b justification, the VS Code limitation paragraphs in step 9) to the operative instruction plus a one-line reason, moving conciseness from 'some unnecessary explanation' toward 'efficient'.
Ship references/token-optimizer.md (referenced at the top of the body but absent from the bundle), or remove the dangling pointer; if shipped, split the setup install script and the benchmark record-field/cost-model detail into it so SKILL.md stays an overview with clearly signaled one-level-deep references.
Move the per-mode long reference material (doctor's probe-version logic, remove's hash-manifest semantics, benchmark's JSONL schema) into per-mode reference files linked from each mode header, which would both fix the dangling-reference problem and let progressive disclosure score against real bundle structure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Most content is non-obvious operational detail Claude would not know (exact jq hook-registration idioms, client caps, ordering constraints), but extended design-history and justification prose pads the body — e.g. the remove-mode preamble 'Two properties have to hold at once, and an earlier revision traded one away for the other', the step 10b rationale paragraph, and the multi-paragraph VS Code limitations narrative could each be tightened without losing the instruction. This sits between 'mostly efficient but includes some unnecessary explanation' and 'efficient; minor instances of over-explanation' — the verbosity is more than minor, but it is not explaining concepts Claude already knows, so 3 rather than 2. | 3 / 5 |
Actionability | Nearly every step is copy-paste ready: exact bash blocks ('mkdir -p .token-optimizer', the full jq add_group program for .claude/settings.json, the awk model:-rewrite in 10b), a complete .token-optimizer.yaml template, concrete per-mode validation commands, and explicit output formats for doctor/report. Placeholder variables ($client, $chosen_mode, INSTALLED_ASSETS) are each defined by surrounding steps, and the few abstract passages (benchmark record fields) deliberately mirror a manifest file. This matches the anchor 'Fully executable; copy-paste ready code or commands; specific examples cover the common cases'. | 5 / 5 |
Workflow Clarity | Each of the eight modes has a numbered, explicitly-ordered sequence with per-mode validation blocks, and the risky operations carry real feedback loops: an unverified probe downgrades redirect to audit and names the command to re-run ('Run .token-optimizer/probe/run-probe.sh to verify delegation, then re-run setup'), and remove recomputes each hash before any deletion, preserves mismatches, and uses rmdir instead of rm -rf. Ordering constraints are stated with reasons (manifest 'Run LAST', 'Last: drop the manifest, then the directories'). This matches the top anchor for clear sequence, explicit validation, and error-recovery loops. | 5 / 5 |
Progressive Disclosure | The body has real structure (per-mode headers, per-mode Validation sections), but it is a ~680-line monolith in which content that clearly belongs in separate files is inlined (the full benchmark JSONL field list, the remove-mode hash-manifest semantics, the complete setup install script), and its single reference — 'Read references/token-optimizer.md before responding' — is a one-line pointer to a file that does not exist in this bundle (no references/ directory is present), so the pointer is neither clearly signaled per-section nor loadable. This is above 'minimal structure / buried references' (2) because headers and validation sections make it navigable, but below 'most content appropriately placed' (4) because of the dangling reference and the bulk detail that should live in reference files. | 3 / 5 |
Total | 16 / 20 Passed |