Content
81%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 a highly actionable, well-sequenced operational policy with concrete commands, explicit error-recovery loops, and a well-integrated single reference file. Its main weakness is token efficiency: dense, hard-to-parse passages and some repetition (provenance flags, update-notice policy) could be tightened or offloaded to the existing references file.
Suggestions
Consolidate the provenance-flag guidance (currently shown in Quick start and restated in Configuration) into a single place, keeping only the stamped example command.
Move the peripheral skill-update notice policy and the manual-update procedure detail into the existing references/skill-updates.md, leaving a one-line pointer in the body.
Rewrite the sandbox auth diagnostic and preflight reuse rules as short checklists to cut dense multi-clause sentences like 'Reuse a successful check in the same executable/workspace/deployment and execution context'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~190-line body avoids teaching known concepts, but several dense procedural passages could be tightened (e.g., 'Reuse a successful check in the same executable/workspace/deployment and execution context; request each required host approval') and provenance-flag guidance is repeated across Quick start and Configuration. This fits anchor 3 ('mostly efficient but could be tightened') better than anchor 4, where verbosity would be only minor. | 3 / 5 |
Actionability | Fully executable commands with exact flags ('qodo read codebase grep --repo owner/repo --pattern "chargeCard" --json'), three worked examples with expected output, and a catalog-verification command ('qodo read tools <group> [<tool>] --json') that resolves the illustrative-tool-name caveat — copy-paste ready and covering the common cases. | 5 / 5 |
Workflow Clarity | Sections are ordered as an execution flow (compatibility gate → preflight → route to a tool group → narrow then fetch → deliver) with explicit validation checkpoints (unadorned --version probe with a minimum-version gate, one-retry rules) and feedback loops ('Empty or truncated: true → narrow once and retry', 'MT-TOOL-LOOP error means stop and change approach'). | 5 / 5 |
Progressive Disclosure | One clearly signaled, one-level-deep reference ([manual-update procedure](references/skill-updates.md), verified to exist) appropriately holds the peripheral update procedure. Not anchor 5: the body is a self-contained policy document rather than an overview pointing to detailed materials, and peripheral policy (update-notice handling, the sandbox auth diagnostic) arguably belongs in references alongside it. | 4 / 5 |
Total | 17 / 20 Passed |