Content
67%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 well-structured instruction-only skill with a clearly sequenced four-phase workflow, concrete templates, and explicit user-confirmation checkpoints. Its main weakness is redundancy: the activation/decision guidance is repeated across multiple sections and could be consolidated into one decision block.
Suggestions
Consolidate "Use this first when", "Do NOT use for", "When to use this skill", and the "Decision rule" section into a single use/skip decision block — the same guidance is currently stated four times.
Add explicit feedback handling at phase gates, e.g. what to do when the user rejects requirements.md or design.md (revise and re-confirm before proceeding).
Define the <spec_name> naming convention and consider moving the EARS pattern syntax and task-format template to a reference file if the skill body grows.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The use/skip decision is restated four or more times across "Use this first when", "Do NOT use for", the "Minimal checklist", "When to use this skill", and the "Decision rule" sections, which could be consolidated. There is no padding with concepts Claude already knows, so it sits at 'mostly efficient but could be tightened' rather than the noticeably-verbose anchor 2. | 3 / 5 |
Actionability | Concrete guidance throughout: exact artifact paths ("specs/<spec_name>/requirements.md"), a copy-paste EARS template with a worked example ("When the user submits the form, the booking system shall validate required fields..."), and a task-format markdown template. Minor gaps — the <spec_name> naming convention is undefined and no fully worked artifact example is provided — keep it below 5. | 4 / 5 |
Workflow Clarity | Phases 1-4 are clearly sequenced with explicit confirmation checkpoints ("Require confirmation between requirements, design, and task breakdown"; "Only start implementation after the user confirms the task plan"). It is not 5 because there is no explicit feedback loop for what to do when the user rejects or revises a phase output. | 4 / 5 |
Progressive Disclosure | Sections are well organized with clear headers, and sibling-skill references are one level deep and condition-signaled ("Frontend page or visual design work -> ../ui-design/SKILL.md"). At ~150 lines the EARS pattern syntax and task-format template could live in reference files, so it does not reach the fully-split anchor 5. | 4 / 5 |
Total | 15 / 20 Passed |