Content
71%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, copy-paste-ready command reference with a well-specified confirmation policy for destructive operations. Its weaknesses are token efficiency and structure: hundreds of lines restate standard Redis syntax Claude already knows, all of it inline in SKILL.md rather than split into a reference file, and the referenced scripts/upstash-client.ts is missing from the bundle, leaving the only file pointer in the body broken.
Suggestions
Move the full Redis command listings (String/Hash/List/Set/Sorted Set/Key/Server sections) into a references/commands.md file, keeping only the invocation pattern, credential overrides, a few representative examples, and the confirmation policy in SKILL.md — this addresses both the conciseness and progressive-disclosure gaps.
Trim or remove the standard Redis syntax documentation (e.g., '# Push to head', 'Sets store unique, unordered members') and retain only the wrapper's non-standard behavior: its CLI option flags (--ex, --withscores, --limit off,count), output format, and error semantics, which are what Claude cannot infer.
Ship the referenced scripts/upstash-client.ts in the bundle (no scripts/ directory currently exists) or fix the path so the only file reference in the body resolves to a real file, and add a brief post-write verification step (e.g., read the key back after critical writes) to the workflow section.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Quotes: "LPUSH <key> <val1> [val2...] # Push to head", "ZRANGE <key> <start> <stop> [--withscores] [--rev]...", "Sets store unique, unordered members". The wrapper-specific material (bun invocation, --url/--token override, output format, confirmation policy) earns its place, but roughly 250 of the ~430 lines re-list standard Redis command syntax and data-type explanations Claude already knows, so it is mostly efficient but could be tightened considerably — not anchor 5's every-token-earns-its-place, and not anchor 2 since the script-specific parts are genuinely non-obvious and the listings are terse rather than padded prose. | 3 / 5 |
Actionability | Quotes: "bun run scripts/upstash-client.ts <command> [args...]", "bun run scripts/upstash-client.ts HSET user:1 name "John" email "john@example.com" age 30", "bun run scripts/upstash-client.ts --url "https://..." --token "AX..." GET mykey". Every command family has copy-paste-ready invocations with worked examples covering common cases (queues, tags, leaderboards, session TTL), fully matching the top anchor. | 5 / 5 |
Workflow Clarity | Quotes: "Before executing any destructive operation (write, modify, or delete), you MUST ask the user for confirmation", the YOLO-mode indicators list, and "If credentials are missing or invalid, the script will exit with an error message". The destructive-operation confirmation gate and error path satisfy the validation requirement, so the destructive-skill cap at 3 does not apply, and the single action (run one command) is unambiguous; it falls short of anchor 5 only for lacking a post-write verification step or broader error-recovery feedback loop beyond credentials. | 4 / 5 |
Progressive Disclosure | Quotes: "## Command Reference" followed by ~300 lines of inline command listings, and the repeated "scripts/upstash-client.ts" reference. Section headers are clear and the layout is scannable, but the bulk command reference is exactly the content the rubric says belongs in a separate file, no references/ files exist, and the one path the body depends on (scripts/upstash-client.ts) is absent from the bundle (no scripts/ directory present) — matching anchor 3's 'content that should be separate is inline' rather than anchor 4's appropriately split structure, though the internal organization is too good for anchor 2's 'minimal structure'. | 3 / 5 |
Total | 15 / 20 Passed |