Conciseness

The body is dense operational policy with essentially no filler — it never explains GitHub basics Claude already knows, and every section carries rules. It is not a 5 because roughly the checked_gh.py contract stretch (lines 92–131, e.g. 'removes inherited GH_REPO and alternate token variables from the child, and rejects conflicting host operands') and the incident-attribution paragraph duplicate material that the linked script documents and could be trimmed or pushed to a reference.

Actionability

Fully executable, copy-paste-ready commands with explicit flags and --json/--jq field lists: 'gh auth status --hostname HOST', 'gh repo view OWNER/REPO --json nameWithOwner,visibility,isPrivate...', the 'uv run python <github-ops-dir>/scripts/checked_gh.py --expected-login <EXPECTED_LOGIN> --host HOST -- pr edit <NUMBER> -R OWNER/REPO --title ...' invocation (verified against scripts/checked_gh.py, whose flags match), and a concrete read-only quick reference. This matches the 'fully executable, covers the common cases' anchor.

Workflow Clarity

An explicit eight-step universal operating contract (classify → bind identity → read current authority/preview delta → choose interface → mutate once → independent readback → report outcome → scoped authentication) with a mutation-to-evidence table, retry policy for non-idempotent writes, bounded polling for async state, and honest four-state reporting with recovery paths — exactly the clear-sequence-with-explicit-validation-and-feedback-loops pattern of the top anchor.

Progressive Disclosure

A task-to-reference routing table cleanly sends each operation class to one of 11 one-level-deep references (all verified present in references/), with the helper script linked and its contract pointed to scripts/checked_gh.py; the body holds only the universal contract and routing, which is the appropriate split. This matches the 'clear overview with well-signaled one-level-deep references' anchor.

Specificity

The description enumerates a comprehensive set of concrete capability areas — 'PRs, issues, Actions, repos, collaborators, org permissions, 2FA' via 'gh CLI and REST/GraphQL' — plus an operating discipline ('explicit target, authorization, and independent readback'). It falls just below the 5 anchor because capabilities are named as objects rather than concrete actions (no 'create', 'merge', 'close', 'delete' verbs), leaving minor gaps in what the operations actually are.

Completeness

Both parts are explicit: the 'what' ('Operates GitHub via gh CLI and REST/GraphQL — PRs, issues, Actions, repos...') and a 'Use when' clause ('Use when a write reports success but state didn't change, or choosing gh/REST/GraphQL/UI-only'). It is not a 5 because the 'when' covers a narrow slice of triggers — failure-verification and interface-choice scenarios — and never states the natural top-level trigger 'when working with GitHub' or 'when asked to create/merge a PR', so routine GitHub requests are only weakly implied.

Trigger Term Quality

Natural user-facing terms are well covered: 'GitHub', 'PRs', 'issues', 'Actions', 'repos', 'collaborators', 'permissions', '2FA', 'gh CLI', 'REST/GraphQL', and 'write reports success but state didn't change'. A few common variations users would naturally say are missing — the spelled-out 'pull request', 'merge', 'create repo', ' Actions workflows' — so it sits at the 'good coverage, a few natural terms missing' anchor rather than comprehensive.

Distinctiveness Conflict Risk

Clear niche — GitHub-hosted state operations with verification discipline — reinforced by explicit negative triggers naming sibling skills: 'Not for local Git recovery (use git-safety-net), maintainer PR review (use github-review-pr), or upstream contribution (use github-contributor)'. This is stronger than the 4 anchor, which only has minor overlap risk with no such routing disambiguation.