Content
92%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 is an exemplar of operational writing: every step is an executable command, both relay and local flows carry explicit verification probes, and the pitfalls encode hard-won failure knowledge (reasoning_effort 400s, context-window overflow masquerading as SSE bugs, download-id vs installed-name confusion) with concrete remediation. The only criticism is modest duplication between the Quick Reference table, the How-to-Run steps, and the Verification section, which could be consolidated to save tokens.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with non-obvious operational knowledge (exact commands, error strings like 'Expecting value: line 1 column 1 (char 0)' and 'Provider returned an empty stream', issue numbers, and the 409-without-quantization rule) and explains nothing Claude already knows. It loses a point to duplication rather than padding: the Quick Reference table repeats values already stated in How to Run (relay URL, ACTUAL_API_KEY, ACTUAL_BASE_URL, provider id), and the Verification section repeats the same 'hermes chat -Q -q ...' commands verbatim from the step lists. This is 'efficient; minor instances... that could be trimmed' (anchor 4), not anchor 5's 'every token earns its place'. | 4 / 5 |
Actionability | Every step is a copy-paste-ready command: curl for model discovery, 'hermes config set model.provider actual', 'actual models download "Qwen/Qwen2.5-0.5B-Instruct-GGUF/Q4_K_M"' with the exact repo/quant string, and verification probes with deterministic expected outputs ('Reply with exactly: ACTUAL_OK' / 'LOCAL_OK'). The few placeholders (MODEL_ID_FROM_DISCOVERY, INSTALLED_MODEL_NAME) are not gaps — the preceding discovery steps tell you exactly where to get their values, and the skill distinguishes download ids from installed names explicitly. This matches anchor 5: 'Fully executable... specific examples cover the common cases'. | 5 / 5 |
Workflow Clarity | Both flows (relay and local) are clearly numbered with explicit validation checkpoints at each phase — verify the key via /v1/models, verify end-to-end with a deterministic probe, verify with a reduced toolset in local mode. Error-recovery feedback loops are present throughout: expired device codes ('re-run actual for a fresh one'), 400s on reasoning effort (clamp or 'agent.reasoning_overrides.<model>: high'), empty-stream symptom with three concrete fixes, and 409 downloads ('explicit quantization'). This is anchor 5: 'Clear sequence with explicit validation steps; feedback loops for error recovery'. | 5 / 5 |
Progressive Disclosure | The body is a well-sectioned overview (When to Use, Prerequisites, How to Run, Quick Reference, Pitfalls, Verification) that keeps core workflow inline while offloading the peripheral OpenCode-client integration to a single clearly signaled one-level-deep reference ('For other OpenAI-compatible clients (e.g. OpenCode), see references/opencode.md' — the file exists in the bundle). There is no nesting of references and no monolithic inline dump of material that belongs elsewhere. This fits anchor 5: 'Clear overview with well-signaled one-level-deep references... easy navigation'. | 5 / 5 |
Total | 19 / 20 Passed |