Content
81%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 body is highly actionable and workflow-safe: exact commands, verbatim ruleset patterns, named CI contexts, and explicit validation and error-recovery paths for push rejections and label-permission failures. Its main cost is token efficiency — core rules are repeated across sections and standard Conventional Commits format is over-taught — and the single-file layout inlines reference-worthy policy tables.
Suggestions
State each core rule once (in Critical Rules) and reference it from the Workflow and Commands sections instead of restating the fork/push and label-permission rules three to four times.
Trim the Conventional Commits section to the project-specific parts (the enforced regex, the type→PR-label mapping, breaking-change '!' convention) and drop the generic format explanation and invalid examples Claude can already derive from the pattern.
Move the branch-naming and commit-type tables into a reference file (e.g. references/naming.md) linked from a short inline summary to reduce SKILL.md's inline footprint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Most sections are dense project-specific policy Claude would not know (ruleset patterns, check names, fork conventions), but core rules are each restated three or more times — the fork/push rule appears in Critical Rules #5, the Commands comments, and the 'When a push to the canonical repository is rejected' section; the label-permission rule in Critical Rules #6, Workflow step 7, and Commands — and ~60 lines teach standard Conventional Commits format (including 'Fix bug ← no type prefix' invalid examples) that Claude already knows. Mostly efficient but noticeably tightenable; below anchor 4 due to the repeated rules and known-concept tutorial, above anchor 2 because the bulk is genuinely non-redundant project policy. | 3 / 5 |
Actionability | The Commands section gives copy-paste-ready commands with explicit flags ('git push -u origin feat/my-feature', 'gh pr create --repo <canonical-owner>/<canonical-repo> --head <your-fork-owner>:feat/my-feature --base main'), the branch and commit regexes are stated verbatim, the checks table names exact job names, and error signatures ('GH013', 'AddLabelsToLabelable') are quoted so failures are recognizable. The only placeholders are unavoidable repo/user-specific values, matching the anchor-5 example of executable commands covering common cases. | 5 / 5 |
Workflow Clarity | The 8-step Workflow is clearly sequenced with explicit validation checkpoints (step 1 verify issue status/approval, step 4 run and record actual test outcomes, step 5 transient-artifact check, step 8 wait for CI and report only after results), plus a re-validation feedback loop ('Re-run native validation after issue approval/assignment changes; do not rely on stale green checks'). Dedicated error-recovery sections cover both push-rejection modes and the label-permission refusal with exact next actions, matching the anchor-5 pattern of sequence + validation + recovery loops. | 5 / 5 |
Progressive Disclosure | No bundle files exist, and the body appropriately defers bulk policy to clearly signaled one-level-deep repo links ('Use the [canonical PR template](../../.github/PULL_REQUEST_TEMPLATE.md) as the source for body shape; do not duplicate its structure here', CONTRIBUTING.md anchors, contribution-policy-transition.md) instead of duplicating them. It falls short of anchor 5 because ~130 lines of branch-naming and conventional-commit tables/patterns are inlined in SKILL.md where reference files would keep the overview leaner, though that content is operationally justified at decision time. | 4 / 5 |
Total | 17 / 20 Passed |