Content
63%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 skill body is well-organized with a clear five-step workflow and exemplary progressive disclosure to a single real, one-level-deep reference file. Its weaknesses are redundant repetition of the non-ingestion constraint (which inflates token cost) and instruction-level guidance that names commands and handoffs without showing concrete invocations or artifact examples.
Suggestions
State the non-ingestion constraint once in Constraints and reference it from the workflow steps instead of repeating the full 'issue, milestone, body, comment, title, label, or summary text' enumeration four times.
Show the gate commands as concrete invocations (e.g., a fenced block with 'gh --version' / 'gh auth status' and the expected check) and give one example of a repository-owned planning artifact path (e.g., 'openspec/changes/<change-id>/' or 'docs/adr/0007.md').
Drop the 'When to use this skill' section — it duplicates the frontmatter description verbatim — and add a brief recovery step for when 'gh auth status' fails or the artifact path is invalid.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body repeatedly states the same core constraint — the 'issue, milestone, body, comment, title, label, or summary text' non-ingestion enumeration appears nearly verbatim in the intro, Constraints ('NO ISSUE TEXT INGESTION'), Step 3, and Step 4, and the 'When to use this skill' section restates the description's trigger list. It is mostly lean (no explanation of concepts Claude already knows) but could be tightened considerably, matching 'mostly efficient but could be tightened' rather than the 2 anchor's several unnecessary explanations. | 3 / 5 |
Actionability | Concrete elements exist (specific commands 'gh --version', 'gh auth status', 'gh auth login', '--repo' from git remote, the stop-and-ask install gate, and the chain to '@014-agile-user-story'), but the commands are named rather than shown as runnable invocations, and Steps 3–4 give no concrete detail on what the operator-side inventory involves or what a 'repository-owned planning artifact path' looks like. This lands at 'some concrete guidance but incomplete / missing key details', not 4's mostly-executable bar. | 3 / 5 |
Workflow Clarity | A clear five-step sequence with an explicit interactive gate ('stop, ask, wait') and an availability check as a checkpoint; constraints are bolded for emphasis. It misses 5 because there are no validation/feedback checkpoints after the gate — e.g., what to do if 'gh auth status' fails or if the provided artifact path is missing — leaving 'minor validation gaps' at the 4 anchor. | 4 / 5 |
Progressive Disclosure | The body is a ~55-line, well-sectioned overview that delegates detail to a single clearly signaled one-level-deep reference — 'For detailed guidance, examples, and constraints, see [references/043-planning-github-issues.md]' — and that file exists and contains no further nested references. This matches the anchor for a clear overview with well-signaled one-level-deep references and easy navigation. | 5 / 5 |
Total | 15 / 20 Passed |