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 delivers strong concrete configuration and command guidance, but it is noticeably verbose: six provider env blocks duplicate the existing (never-referenced) references/.env.example, conceptual narrative sections pad the token budget, and destructive database-reset steps lack validation checkpoints.
Suggestions
Replace the six inlined provider env blocks with a compact provider-selection table and point to references/.env.example (which already contains all of them), e.g. 'Full provider env vars: see references/.env.example (GRAPHITI section)'.
Cut the 'How Memory Works' and 'Memory in Action' narrative sections and the 'Effective Memory Use' platitudes — they restate concepts inferable from the config and tool tables.
Add validation around destructive steps: verify the backup exists before the mv-based database reset, and confirm the new OLLAMA_EMBEDDING_DIM matches the new model before running rm -rf on the embeddings directory.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~370-line body inlines six full provider env blocks (~80 lines) that already exist in the bundled references/.env.example, plus conceptual padding Claude does not need: "How Memory Works", the "Memory in Action" session narrative, and platitudes like "Don't force memory storage" and "Query with natural language". This matches anchor 2 (several unnecessary explanations or padded sections); it is not 3 because the duplication with the existing reference file and the multiple narrative sections go beyond 'some unnecessary explanation', and the rubric penalizes verbosity even when accurate. | 2 / 5 |
Actionability | Mostly executable, copy-paste-ready guidance: complete env blocks per provider, install commands ("ollama pull deepseek-r1:7b"), CLI queries ("python query_memory.py --search \"authentication\""), and troubleshooting commands (curl provider checks, backup/reset). Minor gaps keep it from 5: Python examples use unexplained placeholders ("get_graphiti_memory(spec_dir, project_dir)") with no concrete values, and the MCP tools are named in a table without usage syntax. | 4 / 5 |
Workflow Clarity | Sections exist for enable → provider selection → database → querying → troubleshooting, and troubleshooting includes some verification commands, but there is no coherent sequenced setup walkthrough and no explicit checkpoints. The destructive database operations ("rm -rf ~/.auto-claude/memories/embeddings", the mv-based reset) lack validation loops (no backup verification, no dimension confirmation before wiping), so per the scoring notes workflow_clarity is capped at 3; it stays above 2 because verification commands do appear in the troubleshooting section. | 3 / 5 |
Progressive Disclosure | The body has well-organized section headers and tables (some structure), but the 13KB references/.env.example — which already documents every GRAPHITI provider setting inlined in the body — is never referenced or signaled anywhere in SKILL.md, and content that clearly belongs in that separate file (the six provider config blocks) is inline. This matches anchor 3: references present but not clearly signaled, content that should be separate is inline; it is not 2 because the internal section structure is genuinely good, not minimal. | 3 / 5 |
Total | 12 / 20 Passed |