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.
An exceptionally actionable and well-validated operational skill: exact commands, JSON payloads, dry-run/approval/read-back gates, and error-recovery loops for destructive and bulk operations. Its weaknesses are length — approval and outcome rules are repeated across at least five sections, and version-stamped details sit in the quick start — and the large inlined review-skills configuration flow that belongs in a separate reference file.
Suggestions
Consolidate the repeated approval/dry-run/read-back/idempotency rules into the single 'Guardrails' section and reference it from 'Instructions', 'Preflight', and 'The four jobs' instead of restating them, cutting significant duplicate text.
Move the 'Set up or manage imported review skills' flow (~lines 170–349) into a dedicated references/review-skills.md and keep a short routing summary in SKILL.md, matching the conditional-loading pattern already used for the Windows and update references.
Move the pinned version details ('2.0.0 or newer' minimum, '--skill-version 1.0.8') out of the quick-start command block into a compatibility section, so time-sensitive constants don't penalize the otherwise copy-paste-ready quick start.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 480-line body is dense with domain-specific policy (not concepts Claude already knows), but the approval/dry-run/read-back/idempotency rules are restated across many sections ("Instructions", "Preflight", "The four jobs", "Guardrails", "Report the verified outcome"), and version-sensitive values ("2.0.0 or newer", "--skill-version 1.0.8") appear in the quick start outside any deprecation section. Not a 2 because nearly all content is operational policy rather than padding or explanation of known concepts; not a 4 because the cross-section repetition and duplicated reporting guidance could be meaningfully consolidated. | 3 / 5 |
Actionability | The body supplies copy-paste-ready commands with exact JSON payloads (e.g. `qodo rules set-state --args '{"rule_ids":[123,124],"state":"inactive","dry_run":true}' --json`), concrete error codes ("MT-RATE-LIMITED"), worked scope-derivation examples for both `git@host:a/b` and `https://host/a/b`, and a bulk-operation table — covering the common cases for all four jobs. The "illustrative, not guaranteed current" caveat is an explicitly justified flexibility (live-schema verification is mandated), so it does not reduce actionability. | 5 / 5 |
Workflow Clarity | Every workflow is explicitly sequenced with validation checkpoints: numbered preflight steps, a 6-step discovery procedure with polling budgets, preview → approve → apply → read-back for writes, and "Every bulk operation runs with `dry_run=true` first" with matched-count inspection before the real call. Feedback loops are present in Error Handling ("after a timeout or transport failure, read back the target before retrying ... Retry at most once"), satisfying the destructive/batch validation requirement. | 5 / 5 |
Progressive Disclosure | The three bundle files (references/skill-updates.md, windows-shells.md, windows-launcher.md) exist, are one level deep with no nested references, and are conditionally loaded at sensible points (Windows shell guidance "before the first call", launcher recovery "only if invocation fails"). Not a 5 because the ~180-line imported-review-skills configuration flow is fully inlined in SKILL.md rather than split into a reference file, leaving the main file a monolithic procedure manual rather than an overview; not a 3 because the references that do exist are clearly signaled and appropriately placed. | 4 / 5 |
Total | 17 / 20 Passed |