Content
56%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 contains dense, genuinely non-obvious policy with strong validation and safety gating for a destructive-capability (merge) workflow, and its commands are largely executable. Its weaknesses are heavy repetitive boilerplate across the owner-exception sections, a monolithic structure with no reference files, and an undefined 'unknown-membership policy' it leans on repeatedly.
Suggestions
Factor the repeated 'does not waive the ultra-scary safety gate / external-author prohibition / independent-review requirement' clause out of each owner-exception paragraph into a single shared statement applying to all exceptions.
Split stable detail — the per-owner exception roster and the merge-queue/dequeue command sequences — into reference files (e.g., references/owner-exceptions.md, references/merge-procedure.md) linked from a shorter SKILL.md, and give the concrete `gh` command for the organization membership API instead of naming it abstractly.
Define or explicitly link the 'existing unknown-membership policy' the body cites at least four times; it is load-bearing for approval and readiness decisions but never specified here.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | At ~490 lines the body restates the same waiver boilerplate in nearly every owner-exception paragraph — "This exception does not waive the ultra-scary safety gate, the external-author prohibition, or the independent review requirement for..." appears with minor rewording for Alice/Nick, Shomix, Sid/Enzo, Manu, shawnmcclelland, and kapunahelewong/Wes, and merge-gate conditions (pending/failed/unknown not satisfied, same-head pinning) are repeated across sections. This is noticeably verbose with several padded, duplicative sections — it does not explain concepts Claude already knows, so it stays above the 'severely verbose' anchor, but the repetition goes beyond the 'could be tightened' level. | 2 / 5 |
Actionability | Much of the guidance is executable and copy-paste ready: the rulesets listing command, the guarded `gh pr merge --squash --admin --match-head-commit` and queue variants, the dequeue GraphQL mutation, the ship command, and the recap table template. It falls short of the top anchor because some key procedures are named but never shown — the "organization membership API" is invoked repeatedly with no concrete `gh` command, and PR selection ("List open PRs newest by creation or update time") has no command. | 4 / 5 |
Workflow Clarity | The pipeline is sequenced (selection gates → evidence sweep → approval policy → merge-readiness → 10-minute gate → merge → recap) with strong validation checkpoints and genuine feedback loops: gate reset on push/failed check/new feedback, immediate dequeue plus `--disable-auto`, revalidation immediately before the admin merge, and post-merge verification that the merge commit is an ancestor of origin/main. It is not a 5 because the flow is spread across many interlocking sections and repeatedly defers to "the existing unknown-membership policy", which is never defined or linked in this body — a real gap for a merge-authorizing skill. | 4 / 5 |
Progressive Disclosure | There are no bundle files at all; everything — per-owner exception rosters, merge-queue mechanics, handoff drafting rules — is inlined in one ~490-line SKILL.md with only a one-line "Related skills" pointer. Section headers keep it navigable (above the 'minimal structure, no headers' anchor), but content that clearly belongs in separate reference files is inline with no progressive disclosure, matching the 'some structure but could be better organized; content that should be separate is inline' anchor. | 3 / 5 |
Total | 13 / 20 Passed |