Content
73%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 dense, highly actionable instruction skill with strong workflow sequencing and validation culture. Its main cost is token weight: repeated authorization boilerplate and over-engineered sentences inflate the body without adding information, and the branch step lacks a concrete command.
Suggestions
State the authorization requirement once in a single section (e.g. under 'Verification protocol') and reference it elsewhere ('per the authorization rule above') instead of repeating the full sentence in four places.
Make the 'Branch' step concrete: give the actual `git checkout -b <type>/<short-description>` command with one matching example branch name instead of a comment-only block.
Move the chained-PR strategy detail (Stacked vs Feature Branch Chain pros/cons) and the anti-patterns table into referenced files, keeping only the decision rule and a few top anti-patterns inline.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body does not explain concepts Claude already knows, but the authorization boilerplate ("obtain explicit authorization for the exact remote destination, operation and credential/session") repeats nearly verbatim across at least four sections, and several sentences are convoluted (e.g. the rule-3 canonical issue-creation contract sentence). Anchors for 4 require efficiency with only minor over-explanation; the repetition here is more than minor. | 3 / 5 |
Actionability | Provides copy-paste-ready commands (`gh pr view <N> --repo "$TARGET" --json labels,closingIssuesReferences,additions,deletions,changedFiles`), exact regexes, and a per-section PR template mapping. Not a 5 because the 'Branch' step is a comment-only pseudocode block with no executable command, and several rules defer mechanics to external files without a concrete example. | 4 / 5 |
Workflow Clarity | The PR workflow (steps 1-6) is clearly sequenced with explicit validation gates (local validation: `go build`/`go vet`/`go test`), a pre-PR self-audit checklist, and verification-protocol feedback loops ('if different, request separate authorization before editing the body', 'Compare in an isolated clean base or mark baseline unverified'). This matches the anchor with explicit validation steps, error-recovery loops, and a checklist. | 5 / 5 |
Progressive Disclosure | No bundle files exist locally, and the References section lists one-level-deep external repo files clearly with what each provides ('CONTRIBUTING.md — full workflow, label taxonomy...'). Structure is good, but some inline content (the chained-PR strategy section and the long anti-patterns table) is detailed enough that it could live in a referenced file, keeping it at 4 rather than 5. | 4 / 5 |
Total | 16 / 20 Passed |