Content
60%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's reference material is genuinely concrete (exact regexes, complete label mappings, worked commit examples) and the workflow is well-gated, but execution guidance is hollow at the point of truth: no actual commands anywhere — the section literally titled "Commands" is a run-on authorization-policy paragraph — and the Critical Rules prose is so dense that its constraints are hard to act on. Splitting policy from procedure and supplying the gh/CI queries the workflow presupposes would sharply improve it.
Suggestions
Put real commands in the "Commands" section (e.g. `gh issue view N --json labels` to verify `status:approved`, `gh api repos/{owner}/{repo}/rulesets` to resolve required checks, `gh pr create --draft` for the draft step) and move the authorization policy into a short bulleted rules list.
Untangle the single-paragraph Critical Rules and Commands prose into discrete one-line rules; constraints like the `viewerPermission MAINTAIN/ADMIN` requirement and the size-exception rationale are currently buried mid-sentence and easy to miss.
Move the branch-naming and conventional-commit tables into a references file (e.g. `references/naming.md`) and keep SKILL.md to the workflow, PR body format, and check gates, shortening the body by roughly a third.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The tables, regexes, and examples are token-efficient, but the run-on "Critical Rules" paragraph and the dense policy prose in "Commands" ("For protected `status:approved` or `size:exception`, require authenticated actor target-host `viewerPermission`...") bury rules in single-sentence walls, and policy constraints (authorization, readback, do-not-assume-main) are repeated across three sections. This is noticeably tighter than anchor 2's padding but carries real unnecessary verbosity, matching anchor 3. | 3 / 5 |
Actionability | Concrete artifacts exist — exact branch and commit regexes, complete type-to-label mapping tables, 11 example commit messages, and a table of CI checks with job names — but the core actions have no executable commands: the "Commands" section contains zero commands (it is a policy paragraph), and there is no command to check an issue's `status:approved` label, read branch rulesets, or create the PR. The PR body template uses schematic placeholders ("<human-selected Closes/Fixes/Resolves #N or Refs #N>") rather than fillable examples. This lands on anchor 3: some concrete guidance but incomplete, with key execution details missing rather than the minor gaps of anchor 4. | 3 / 5 |
Workflow Clarity | The six-step workflow is clearly sequenced with explicit checkpoints: verify `status:approved` before drafting, ask the human for closing vs non-closing intent, read target policy before declaring checks REQUIRED, and mark checkboxes only after readback. It matches anchor 4 rather than 5 because there is no error-recovery loop (what to do when a validation job fails) beyond "report failures honestly", and rather than 3 because the gates are explicit, not implicit. | 4 / 5 |
Progressive Disclosure | A single self-contained file with clear ## sections, a table of contents implied by headers, and no buried or nested references — appropriate for this scale. It stops short of anchor 5 because ~50 lines of conventional-commit and branch-naming reference material plus the tangled policy prose would be better split into a short reference file, leaving SKILL.md as a leaner overview. | 4 / 5 |
Total | 14 / 20 Passed |