Content
76%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 tight, highly actionable gh CLI reference with zero padding and useful --jq recipes and templates. Its main weakness is the absence of validation checkpoints around consequential operations (merge, close, rerun), which the rubric caps workflow clarity at 3 for, and mild redundancy between the body's Use/Don't-Use lists and the frontmatter description.
Suggestions
Add a pre-merge validation checkpoint, e.g. "Before merging: `gh pr checks <PR> --repo <repo>` and confirm all checks pass, then `gh pr view <PR> --json mergeable --jq .mergeable`" — this would lift workflow clarity past the destructive-operation cap.
Add verify-first guidance for other consequential commands (e.g., preview an issue with `gh issue view` before closing, or confirm the run IDs with `gh run list` before `gh run rerun`).
Trim the "When to Use / When NOT to Use" sections or the most basic command listings (plain `gh pr list`, `gh issue create`) that restate the description and gh knowledge Claude already has, keeping the templates and --jq recipes that add real value.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is almost entirely lean command blocks with terse comments and no concept explanations ("Most commands support `--json` for structured output" is one line), matching anchor 4. It falls short of anchor 5 because the "When to Use"/"When NOT to Use" sections and the basic command listings (e.g., plain `gh pr list`, `gh issue create`) largely restate the frontmatter description and gh usage Claude already knows, so some tokens could be trimmed. | 4 / 5 |
Actionability | Every section is copy-paste-ready, executable commands — `gh pr checks 55 --repo owner/repo`, `gh run view <run-id> --log-failed`, `gh api ... --jq '{stars: .stargazers_count}'` — including practical --jq recipes and two ready-to-run templates. This matches anchor 5 ("fully executable; copy-paste ready; covers the common cases"); anchor 4 would imply missing key details or gaps in coverage, which are not present. | 5 / 5 |
Workflow Clarity | Commands are well grouped (PRs, issues, CI, API) but consequential operations lack validation checkpoints: `gh pr merge 55 --squash` is presented with no preceding step to verify checks pass or mergeability, and `gh issue close` / `gh run rerun` likewise have no verify-first guidance. Per the rubric's cap rule, workflows involving destructive operations without validation cannot score above 3 — the only validation shown (`select(.mergeable == "MERGEABLE")`) is a filtering demo, not an explicit checkpoint in a workflow. | 3 / 5 |
Progressive Disclosure | No bundle files exist (no references/, scripts/, or assets/), and the ~130-line body is organized into clear sections (Setup, Common Commands, JSON Output, Templates, Notes) with content appropriately sized for a single file — matching anchor 4's "good structure; most content is appropriately placed". It is not anchor 5 because it exceeds the under-50-line simple-skill case and inlines the templates/API-query material that could arguably live in a one-level-deep reference file. | 4 / 5 |
Total | 16 / 20 Passed |