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.
The body is a dense, repo-specific workflow guide with strong sequencing, explicit validation checkpoints, a pre-PR audit checklist, and concrete gh/go/git commands. Its main weakness is redundancy — the authorization formula and canonical-contract conditions are repeated across many sections — and its length as a single monolithic file with no bundle-level split.
Suggestions
State the authorization requirement ('obtain explicit authorization for the exact target, operation and credential/session; never probe ambient credentials') once in a dedicated section and cross-reference it from the workflow steps instead of repeating the full formula in at least four places.
Consolidate the PR-body honesty rules into the single 'PR body honesty' section and have Hard rules, the pre-PR checklist, and the anti-patterns table reference it, rather than restating the labels/count/failure rules in each place.
Replace the comment-only branch step with a concrete command sequence (e.g. the actual git checkout -b invocation with the branch-name regex) so every workflow step is executable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body avoids explaining concepts Claude already knows and is mostly repo-specific rules, but it is noticeably repetitive: the authorization formula ('obtain explicit authorization for the exact remote destination, operation and credential/session') appears nearly verbatim in at least four sections, the canonical issue-creation contract conditions are restated in Hard rules 3-4, the scope table, and the verification protocol, and PR-body honesty rules are duplicated across Hard rule 8, PR workflow step 4, the PR body honesty section, the pre-PR checklist, and the anti-patterns table. Not 4: the repetition is more than minor trimming — stating each rule once and cross-referencing would cut a substantial fraction of the ~275 lines. Not 2: there is no basic-concept padding and most sections carry real, non-generic information. | 3 / 5 |
Actionability | Concrete, copy-paste-ready commands are provided ('gh pr view <N> --repo "$TARGET" --json labels,closingIssuesReferences,additions,deletions,changedFiles', 'go build ./... ', 'go vet ./... ', 'go test ./internal/...', 'git diff --stat <base>...<head>') alongside exact regexes for branch names and PR titles and a section-by-section PR body template. Not 5: the branch step (PR workflow step 1) contains only comment placeholders with no actual command, and several directive rules (e.g. 'wait without mutation') are prose rather than executable steps. Not 3: the guidance is genuinely executable, not pseudocode, with only minor gaps. | 4 / 5 |
Workflow Clarity | The PR workflow is clearly sequenced (branch → implement → local validation → draft body → chain diagram → post-publication reconciliation) with explicit validation checkpoints ('go build/vet/test' before drafting, pre-PR self-audit checklist with 15 tick-boxes, verification protocol steps 2-4 that cross-check API state), explicit error-recovery feedback loops (the standard honest-rewrite pattern, 'if different, request separate authorization before editing', pending-actions section), and a checklist for the complex process. Mutations (labels, protected labels) are explicitly gated with wait-without-mutation fallbacks, so no risky operation lacks validation. | 5 / 5 |
Progressive Disclosure | The file is well-structured with clear section headers, and the References section points to one-level-deep source-of-truth files in the target repo (CONTRIBUTING.md, PR template, pr-check.yml, sibling SKILL.md files) rather than duplicating their contents — an effective disclosure pattern since the skill triggers only inside that repo. Not 5: no bundle files exist to split into, and the ~275-line monolith inlines substantial detail (full chained-PR strategy comparison, anti-pattern table, honesty pattern) that could live in referenced files; references point to repo paths rather than bundled files, so navigation depends on the target repo being present. | 4 / 5 |
Total | 16 / 20 Passed |