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.
A well-engineered configuration skill: executable diagnostic commands, precise trust/allowlist rules for global vs project config, state-file troubleshooting with explicit error semantics, and an unusually clean per-platform reference split. The remaining improvements are small — trimming the double disclaimer and repeated platform-file pointers, and showing one worked `memsearch config set` example for the core write flow.
Suggestions
Add one worked example of `memsearch config set <key> <value>` — one trusted key without `--project` and one allowlisted indexing key with `--project` — since applying changes is the skill's core write flow.
State the 'this is MemSearch, not the host agent's own memory/config system' disclaimer once at the top and remove the repetition in 'Applying changes'.
Consolidate the repeated 'see your platform reference file' pointers (6+ occurrences) into a single stated rule to save tokens.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and nearly every line is non-obvious, version-gated knowledge Claude cannot infer ('Since v0.4.11, project-local .memsearch.toml is restricted before it is merged', the seven allowlisted project keys, trust rules), but there is minor trimmable redundancy — the 'this is MemSearch ... not the host agent's own memory/config system' disclaimer appears both in the intro and again in 'Applying changes', and 'see your platform reference file' is repeated more than six times — fitting 'efficient; minor instances of over-explanation that could be trimmed' rather than the lean level 5. | 4 / 5 |
Actionability | Diagnosis is fully executable with copy-paste commands (`memsearch config list --resolved`, the MDIR memory-file inspection block, `memsearch stats`, the index-state cat) and complete TOML examples for providers and prompt overrides, but the primary write flow never gets a worked example — 'Use `memsearch config set` for changes' appears without a single concrete `memsearch config set <key> <value>` invocation — a minor gap that keeps it at 'mostly executable ... with minor gaps' rather than 'fully executable'. | 4 / 5 |
Workflow Clarity | The sequence is clear — identify platform via env markers, route intent, run 'Diagnose First' commands, apply changes, then 'show the command, the resolved value, and whether a new session is needed' — with real checkpoints (version check 'before calling the setup healthy', `.index-state.json` status/last_error/failed_files with degraded-vs-error semantics, the `uvx --from memsearch[onnx]` fallback, and 'Ask the user before enabling external or paid providers, ... re-indexing, deleting state'). Validation is present but advisory rather than an explicit validate-then-proceed loop, matching 'clear sequence with most checkpoints present; minor validation gaps'. | 4 / 5 |
Progressive Disclosure | The shared/platform split is exemplary: platform-specific detail lives in five real one-level-deep reference files (all five exist under references/ with no further nesting), navigation is explicit — 'Read ONLY the one file matching your current environment' plus concrete env markers (DSH_HOME, CODEX_HOME, ~/.openclaw, ~/.config/opencode, CLAUDE_PLUGIN_ROOT) — and the inline body is genuine cross-platform shared logic rather than content that belongs in separate files, matching 'clear overview with well-signaled one-level-deep references; content appropriately split; easy navigation'. | 5 / 5 |
Total | 17 / 20 Passed |