Conciseness

Dense, imperative policy text with no concept explanations, no filler, and no padded sections; nearly every clause encodes a non-obvious project rule ("Base-red does not waive a required gate", "A locked fork needs the owner-reviewed credit-preserving fallback"). Every token earns its place by assuming Claude's competence.

Actionability

Concrete, executable process guidance throughout: one isolated worktree per PR, verify the checked-out SHA equals its observed live head before editing, run a RED reproduction then focused and affected suites, and a structured receipt with named fields (base SHA, head SHA, run IDs, artifact references). Not 5 because there are no copy-paste commands/examples and several directives defer entirely to shared files (merge-gates, teardown protocol) without restating key steps.

Workflow Clarity

A clear three-phase sequence (resolve scope and ownership, prepare and validate, evidence and handoff) with explicit pre-flight checkpoints ("Before pushing, verify the remote still equals the observed predecessor; a concurrent change means HOLD") and a full result classification taxonomy. As a batch/destructive-adjacent workflow it has validation, so the cap at 3 does not apply; it stays below 5 because error recovery beyond HOLD lacks explicit fix-and-retry loops and some checkpoint definitions live in external shared files.

Progressive Disclosure

Well-organized sections with the body kept as an overview; shared references are one level deep and clearly signaled with when-to-read conditions ("Read `../_shared/protected-surfaces.md` before any instruction-surface change or merge"). Not 5 because references use bare backtick paths outside the bundle rather than clearly navigable in-bundle files, and no bundle files (references/, scripts/, assets/) exist in this skill directory to verify against.

Specificity

"Inspect and prepare the selected PR queue against its exact current base, repair authorized defects with contributor credit, and report full versus partial validation" lists several distinct concrete actions. It falls short of 5 because the actions are process-level and leave coverage gaps (e.g., what validation entails), but exceeds 3's 1-2 concrete actions.

Completeness

Both what (inspect, prepare, repair, report validation level) and when ("Use for maintainer pre-greening") are explicitly stated, plus an authorization boundary. Not 5 because the when-clause could be more specific with concrete trigger phrases; not 3 because the when is explicit, not merely implied.

Trigger Term Quality

"Use for maintainer pre-greening" plus "PR queue" and "merge" provide some relevant keywords, but common natural variations users would say ("pull requests", "ready to merge", "green these PRs") are missing and the phrasing leans on internal jargon ("pre-greening"). Not 4 because keyword coverage is narrow rather than good-with-minor-gaps.

Distinctiveness Conflict Risk

A clear niche (maintainer pre-greening of a PR queue) with an explicit fence against the nearest competing skill: "merging requires separate owner authorization and the shared merge gates." Minimal risk of triggering for the wrong skill.