Content
78%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 content is highly actionable with concrete commands and config blocks, and the workflow is well-sequenced with validation guidance and destructive-op guards. Its main weaknesses are moderate: a monolithic structure with no reference-file split for the long platform-update and TOML-reference material, and some minor disclaimer repetition.
Suggestions
Move the four platform-specific version/update procedures (lines ~46-81) and the OpenCode TOML/provider reference into a `references/` file (e.g. `references/update-procedures.md` and `references/config-reference.md`), keeping SKILL.md as an overview with one-level-deep links to improve progressive_disclosure.
State the MemSearch-vs-OpenCode disclaimer once near the top and reference it instead of repeating the full sentence again in the closing paragraphs, to tighten conciseness.
Add an explicit validate→fix→re-validate loop for index and maintenance failures (e.g., after reading `.index-state.json` status, 'fix the listed failed_files then re-run `memsearch index` and re-check status') to lift workflow_clarity to a 5.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and mostly assumes Claude's competence — it gives concrete TOML keys, commands, and model defaults instead of explaining what memory or TOML is — with only minor trimmable redundancy such as the 'this is MemSearch memory config, not OpenCode's own' disclaimer restated several times; it is efficient with minor over-explanation, matching the 4 anchor rather than the noticeably-padded 3. | 4 / 5 |
Actionability | It provides copy-paste-ready, executable guidance throughout — `memsearch config list --resolved`, the version-check bash pipeline, fully specified provider TOML blocks with real model names and `env:` API-key refs, and `memsearch config set` usage rules — covering the common diagnostic and configuration cases, matching the fully-executable 5 anchor. | 5 / 5 |
Workflow Clarity | Intent Routing maps request types to flows, Diagnose First gives a sequenced command order, and there are validation checkpoints via `.index-state.json` status fields and an explicit 'ask before re-indexing/deleting state' guard; it falls short of 5 because there is no explicit validate→fix→re-validate feedback loop spelled out for error recovery. | 4 / 5 |
Progressive Disclosure | The ~245-line body is monolithic with no references/scripts/assets bundle and no internal file references (only external doc URLs), so substantial material that could live in separate files — the four platform-specific version-update procedures and the full TOML/provider reference — is inlined; it has good section headers ('some structure') but content that should be separate is inline, matching the 3 anchor. | 3 / 5 |
Total | 16 / 20 Passed |