Content
88%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 highly actionable, well-sequenced workflow with concrete commands, explicit confirmation checkpoints, and a post-create verification loop — all guidance is non-obvious repo-specific policy rather than padding. The main costs are token duplication of the hotfix/release-note rules across three sections and specialized backport policy that would sit better in a separate reference file.
Suggestions
Consolidate the hotfix title grammar and bilingual release-note structure into one authoritative section (e.g., a 'Hotfix classification' subsection) and reference it from steps 4, 7, and Constraints instead of restating it three times.
Move the release-branch / backport / release-sync targeting policy (step 4, bullets on `release/v<version>`, `backport/v<version>/pr-<number>`, `release-sync/v<version>`) into a reference file such as `references/branch-policy.md`, keeping SKILL.md to the core create-PR workflow and linking to it.
Add the concrete commands for the base-branch inspection step (e.g., `git merge-base`, `git rev-parse --abbrev-ref @{upstream}`) so step 4's 'inspect its merge base and upstream' is as executable as the rest of the workflow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and entirely repo-specific policy Claude would not know (release-branch rules, hotfix title grammar, bilingual release-note fence), with no filler explanations. However, the hotfix title and release-note rules are restated three times — in step 4 ('Use the title `hotfix: <description>`...'), step 7 ('use an exact classifier-compatible title...'), and Constraints ('Never use a `hotfix` title...') — which could be consolidated. Anchor 4 ('efficient; minor instances that could be trimmed'), not 5 because the triplication is real token cost; not 3 because none of it is explanation of things Claude already knows. | 4 / 5 |
Actionability | Fully executable commands with exact syntax: `git push -u <remote> <head-branch>`, the heredoc temp-file pattern with `pr_body_file="/tmp/gh-pr-body-$(date +%s).md"`, `gh pr create --base <base> --head <head> --title "<title>" --body-file "$pr_body_file"`, and the exact `<!--LANG:en-->` bilingual block. Covers the common cases copy-paste ready; matches anchor 5. Not 4: the only non-command guidance ('inspect its merge base and upstream') is peripheral and no concrete step is missing. | 5 / 5 |
Workflow Clarity | Nine clearly ordered steps with explicit checkpoints: push-state check before create (step 3), base-branch gating rules (step 4), preview plus 'ask for explicit confirmation before creating' (step 6), and a post-create feedback loop — 'verify that the classifier added `hotfix`; if it did not, fix the title' (step 7). This is a creation flow with validation present, so no destructive/batch cap applies. Not 4: validation and error-recovery loops are explicit, matching anchor 5. | 5 / 5 |
Progressive Disclosure | No bundle files exist and everything is inline in a single, well-sectioned file (Workflow, Constraints, Command Pattern) with clear headers and no nested references — good structure overall. At ~100 lines, the specialized release-backport/hotfix policy ('A `backport/v<version>/pr-<number>` head must target...') is a distinct sub-topic that could be split into a reference file. Anchor 4 ('good structure; most content appropriately placed; minor organization gaps'), not 5 since the one-file layout isn't ideal for the amount of specialized policy; not 3 because navigation is easy and nothing is buried. | 4 / 5 |
Total | 18 / 20 Passed |