Conciseness

The body is dense and assumes competence (no explanations of gh, go test, or CI basics), but it embeds time-sensitive specifics — 'Between 2026-06-21 and 2026-09-16', 'on 2026-09-15 seven autofix PRs were open' — and repeats case-file anecdotes inline (PR #1073's 2,465 lines, #1110's netlify-cli bump, #1145's ten-minute gap) despite references/case-file.md existing to hold that detail. Per the rubric, undated-section time-sensitive information and duplicable anecdote material penalize conciseness; it is above anchor 2 because none of it is generic padding Claude already knows.

Actionability

Fully executable, copy-paste-ready commands throughout: 'gh run view --job <job-id> --log-failed', 'gh search issues --repo neilotoole/sq --include-prs --limit 20 'TestStartMemStatsTracker'', 'go test ./path/to/pkg -run '^TestName$' -count=20', 'gh workflow run db-integration.yml --ref <your-branch> -f oracle=latest', plus concrete decision tables for classification and gating. Specific examples cover the common cases, matching anchor 5.

Workflow Clarity

A seven-step ordered procedure is laid out in a table up front, each step is anchored and linked, and every step is an explicit checkpoint ('Every step before "Classify" is a possible stop, and stopping early is cheap'). Validation and feedback loops are explicit: reproduce before fixing, dispatch Main Pipeline at least three times for intermittent failures and link each run, 'Re-check prior art immediately before opening', and the final sanity check 'would the failing step have reached the line you changed?'. This matches anchor 5's sequence-plus-validation-plus-feedback structure.

Progressive Disclosure

Structure is good: clear section headers, an overview that motivates the rules, and a well-signaled one-level-deep reference ('references/case-file.md records each one and why it was closed') that exists in the bundle, plus clearly delineated pointers to policy (AGENTS.md) and CI wiring (docs/CI.md). It stops short of anchor 5 because a fair amount of case-file evidence is restated inline in the body rather than fully delegated to the reference, and the body is long (~280 lines) for an overview file.

Specificity

The description names the domain ('CI is red on neilotoole/sq') and several concrete deliverables: 'the triage order, what counts as proof that a fix works, and the rules that keep an attempted fix from landing as a duplicate or unmergeable PR'. It falls short of anchor 5 because it describes what the skill carries rather than enumerating the concrete actions performed, leaving minor coverage gaps.

Completeness

Both what and when are explicitly answered with concrete trigger phrases: 'Use when CI is red on neilotoole/sq and you intend to act on it: an automated autofix pass, a nightly or dispatch failure, or a failing check on a pull request' is an explicit, specific when-clause, and 'Carries the triage order... proof... rules...' states the what clearly. Not below 5 because the when is far more explicit than anchor 4's 'could be more specific'.

Trigger Term Quality

Natural phrases a user would say are present: 'CI is red', 'nightly or dispatch failure', 'failing check on a pull request', 'automated autofix pass'. Coverage is good but misses common variations a user might say such as 'CI failure', 'broken build', or 'flaky test', which is a notable omission given flake triage is a large part of the skill.

Distinctiveness Conflict Risk

The trigger is scoped to a single repository ('CI is red on neilotoole/sq') and to acting on red CI, a clear niche with distinct triggers and minimal conflict risk with any generic CI or testing skill.