Content
78%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 operational skill body: lean checklists, concrete gh CLI commands for every workflow, an explicit validation quality gate, and a well-signaled one-level-deep reference for the high-risk release path. Remaining gaps are minor — a few directional steps without commands (changelog generation, activity checks), validation placed at the end rather than inline, and slight padding around the ECC checklist pointer.
Suggestions
Add the missing commands for directional steps: how to generate a changelog from merged PR titles and a jq filter for 'PRs >5 days with no review', so every workflow step is executable.
Move validation inline into the destructive workflows (e.g. re-verify no response before auto-closing a stale issue, re-confirm green main immediately before tagging) instead of relying solely on the trailing Quality Gate.
Tighten the ECC release paragraph to a one-sentence pointer with its link and trigger conditions; the current two sentences restate the same requirement twice.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is efficient — checklists and gh commands with no explanation of concepts Claude already knows — but has minor trim opportunities: the ECC checklist pitch ("That checklist captures the exact-green-main, signed-tag, registry-readback, and announcement requirements that the generic examples below do not") restates the link's purpose twice, and the raw "Types:" enumeration is lightly padded. This fits the 4 anchor (efficient, minor over-explanation that could be trimmed), not the 5 anchor where every token earns its place. | 4 / 5 |
Actionability | Every section provides executable, copy-paste-ready gh commands (e.g. `gh issue edit <number> --add-label "bug,high-priority"`, `gh run view <run-id> --log-failed`, `gh release create v1.2.0 --title "v1.2.0" --generate-notes`) covering the common cases, but a few steps remain directional: "Generate changelog from PR titles" and "Check age and last activity" have no command. This sits between the 4 anchor (mostly executable, minor gaps) and 5 (fully covering common cases), landing at 4. | 4 / 5 |
Workflow Clarity | Multi-step workflows are clearly sequenced (triage workflow, PR review checklist, CI failure steps, release steps) and validation exists — a Quality Gate checklist ("CI failures have been investigated (not just re-run)") and pre-release validation ("Check all CI is green on main"), so the destructive/batch cap does not apply. It is not 5 because validation checkpoints sit in a trailing gate rather than inline within each workflow (e.g. no explicit re-check step before auto-closing a stale issue), matching the 4 anchor's "most checkpoints present; minor validation gaps". | 4 / 5 |
Progressive Disclosure | The body is a well-sectioned overview, and the single reference (references/ecc-release-checklist.md, verified to exist) is one level deep, clearly signaled with a markdown link and explicit guidance on exactly when to read it and what it covers ("read ... before mutating tags, npm dist-tags, or GitHub Releases"). This matches the 5 anchor: clear overview, well-signaled one-level-deep reference, easy navigation; no buried or nested references exist. | 5 / 5 |
Total | 17 / 20 Passed |