Content
85%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 lean, rigorously sequenced audit workflow with strong validation checkpoints and an explicit completion standard, appropriately kept in a single file. Its weaknesses are localized: step 5's tangled run-on phrasing and a few steps (1, 2, 7) that direct judgment without giving concrete commands or criteria.
Suggestions
Rewrite step 5 into shorter sentences or sub-bullets with one rule each; phrases like "add it to the list of step 6" and "also after the merge, and open no issue for it" currently require re-reading to parse.
Add the concrete commands for verification steps, e.g. `git status` / `git worktree list` in step 7 and the evidence sources to re-read in step 2, matching the specificity step 6 already achieves.
Define what makes verification "weak or stale" in step 4 (e.g. no command output in the transcript, checks older than the last diff) so the re-run decision is mechanical rather than judgmental.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body contains no padding and no explanations of concepts Claude already knows — every line is a directive — but step 5 is over-compressed to the point of confusion ("send it through `review` and `ship`, and add it to the list of step 6", "also after the merge, and open no issue for it"), so brevity partially sacrifices clarity. This matches anchor 4 (efficient, minor instances that could be tightened) rather than anchor 5's "brevity that preserves clarity". | 4 / 5 |
Actionability | Step 6 gives exact executable commands ("gh pr view <url> --json state,mergeCommit", "node scripts/ship-wait-checks.mjs --commit <sha> --follow-main") and steps point to concrete files ("CONTRIBUTING.md", "CLAUDE.md", ".plans/<task>.md"), but several steps lack the how — "Verify branches, worktrees, temporary worktrees, and generated artifacts are clean" names no command, and "Re-run any weak or stale verification" gives no criteria for "weak". Anchor 4 (mostly executable, minor gaps) fits; anchor 3 would require the guidance to be incomplete overall, which it is not. | 4 / 5 |
Workflow Clarity | A clear 1–9 sequence with explicit validation checkpoints: step 6 defines a pass/blocked rule with the exact check command and requires "the blocker and the next action" on failure, steps 2–4 form a verification loop (map criteria to evidence, re-run weak verification), and the closer "Finding no obvious bug is not completion. Prove every requested outcome." sets the exit standard. This matches anchor 5 (clear sequence, explicit validation, feedback for error recovery); the skill is an audit, not a destructive/batch operation, so the workflow-clarity cap does not apply. | 5 / 5 |
Progressive Disclosure | The skill is 49 lines, single-purpose, and ships no bundle files (references/, scripts/, assets/ are absent), so nothing needs offloading; the referenced paths ("CONTRIBUTING.md", "CLAUDE.md", "scripts/ship-wait-checks.mjs") are repository files, one level deep and clearly signaled. Per the simple-skill exception (under 50 lines, no external references needed, well-organized numbered workflow), this scores 5. | 5 / 5 |
Total | 18 / 20 Passed |