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 strong, information-dense operational reference with genuinely non-obvious guidance and good error-recovery coverage. Its main weaknesses are the absence of any progressive disclosure (all domains inlined in one long file) and missing example mutation payloads and post-mutation verification steps.
Suggestions
Split specialized sections (Unified execution monitoring, LLM request diagnostics, Slack quick setup, Event processors) into files under references/ and keep one-line pointers with a brief summary in SKILL.md, so the core operations content loads without the deep detail.
Add a minimal example mutation payload (e.g., a concrete create_bot or update_pipeline tool-call body) so the "same shape as the HTTP API request body" guidance is copy-paste actionable.
Add an explicit post-mutation verification step (e.g., re-fetch the resource with get_* after update_* and confirm the changed fields) to the How-to-use workflow and destructive-operation guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with non-obvious operational facts (401/403 semantics, config replace-not-merge behavior, rkey TTL rules) and assumes Claude's competence, but ~340 lines include run-on prose blocks (Unified execution monitoring, Event processors) that could be tightened, and the time-sensitive marker "Current tools (v1)" sits outside any deprecated/old-patterns section. Not 5 because some passages exceed what strictly earns their tokens; not 3 because there is no padding or explanation of known concepts. | 4 / 5 |
Actionability | Concrete throughout: exact endpoint URL, auth headers, a copy-paste MCP client config JSON, a full tool table, exact HTTP routes (GET /api/v1/system/context, DELETE /api/v1/provider/providers/{uuid}?cascade=true) and named parameters. The minor gap is that mutation payloads are only described as "a JSON object matching the same shape as the corresponding HTTP API request body" with no example object, keeping it below the fully copy-paste-ready anchor. | 4 / 5 |
Workflow Clarity | The "How to use" sequence is clear with a connectivity checkpoint (get_system_info), pre-mutation discovery is mandated, and the Slack setup flow includes an explicit poll-status/authorize/apply loop with 401/403 recovery semantics in Pitfalls. Minor gaps: no explicit post-mutation verification (e.g., re-fetch after update_*), and irreversible deletions rely on cautionary text rather than a validation checkpoint — so it does not reach anchor 5. | 4 / 5 |
Progressive Disclosure | Section headers are clear and external docs are well signaled (docs/en/plugin/dev/permissions.mdx, dev-docs/LLM_REQUEST_POLICY.md), but there is no bundle at all: ~150 lines of specialized detail (monitoring semantics, LLM diagnostics, Slack setup, event processors) is inlined in SKILL.md where the rubric expects an overview with one-level-deep reference files. Structure is present, so it sits above anchor 2, but content that should be separate is inline. | 3 / 5 |
Total | 15 / 20 Passed |