Content
73%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 delivers a well-sequenced, highly actionable verification workflow with exact CLI commands, parse markers, severity levels, and a concrete report format, plus graceful degradation for missing artifacts. Its weaknesses are moderate redundancy between the heuristics, steps, and output-format sections, and evidence-search steps that stop short of concrete tooling guidance.
Suggestions
Consolidate the thrice-stated actionability rule into one place (the Verification Heuristics or Output Format section) and drop the repeated 'Each with specific recommendation' bullets to cut redundancy.
Add concrete tooling for the evidence-search steps, e.g., suggested grep patterns for requirement names ('grep -rn "<keyword>" src/') or where artifacts like specs/design typically live, to close the gap from 4 to 5 on actionability.
If the skill grows, move the report template (step 8) into a references/ file and link to it from the body to keep the main file lean.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and free of explanations of concepts Claude already knows, but the 'Verification Heuristics' and 'Output Format' sections restate guidance already embedded in steps 5-7 (e.g., 'Actionability: Every issue must have a specific recommendation' and 'No vague suggestions like "consider reviewing"' repeat the recommendation requirements). This matches anchor 3 (mostly efficient but could be tightened) rather than 4, since the actionability rule is stated three separate times and the per-priority 'Each with specific recommendation' bullets are trimmable; it is well above anchor 2 because there is no conceptual padding. | 3 / 5 |
Actionability | Concrete copy-paste commands are provided (`openspec list --json`, `openspec status --change "<name>" --json`, `openspec instructions apply --change "<name>" --json`) alongside exact parse markers (`- [ ]` vs `- [x]`, `### Requirement:`, `#### Scenario:`) and a concrete report template with issue-priority formats. Not 5 because the evidence-gathering steps ('Search codebase for keywords related to the requirement', 'Search codebase for implementation evidence') leave a minor gap: no concrete tooling guidance (e.g., grep patterns or where to look), which anchor 5's 'specific examples cover the common cases' would require. | 4 / 5 |
Workflow Clarity | Eight clearly sequenced steps run from change selection through report generation, with explicit branch handling at every point ('If no design.md: Skip design adherence check, note...', 'If incomplete tasks exist: Add CRITICAL issue for each', and the graceful-degradation rules by artifact availability). Severity calibration ('prefer SUGGESTION over WARNING, WARNING over CRITICAL') provides an explicit error-prevention feedback rule. Not 4 because checkpoints and error-recovery branches are explicit throughout rather than only mostly present. | 5 / 5 |
Progressive Disclosure | No bundle files exist, and all content sits in a single ~155-line file with clean, well-labeled sections (Steps, Verification Heuristics, Graceful Degradation, Output Format), which is good structure with appropriately placed content for the current size. Not 5 because the body exceeds the simple-skill range and the report template in step 8 is the kind of material that could move to a reference file as the skill grows; not 3 because nothing is buried and organization is coherent. | 4 / 5 |
Total | 16 / 20 Passed |