Conciseness

The body is lean for a discipline skill: tables, a code-block gate function, and terse ✅/❌ pattern templates with no padding or explanations of concepts Claude already knows. It stops short of anchor 5 because of real redundancy — the 'Red Flags' list and 'Rationalization Prevention' table cover overlapping ground, 'When To Apply' restates the description's triggers, and the garbled line 'Violating the letter of this rule is violating the spirit of this rule' earns no token.

Actionability

The Gate Function is a fully executable five-step procedure (IDENTIFY the command, RUN it fresh, READ output/exit code/failure count, VERIFY, only then claim), the claims table maps each assertion to its required evidence ('Tests pass' → 'Test command output: 0 failures'), and the Key Patterns are copy-paste-ready claim templates ('[Run test command] [See: 34/34 pass] "All tests pass"'). Per the rubric's instruction-skill note, the absence of literal code is not penalized when the guidance is this concrete.

Workflow Clarity

The gate is a clearly sequenced workflow with validation as its core: step 4 branches on evidence ('If NO: State actual status with evidence; If YES: State claim WITH evidence'), and the regression-test pattern embeds an explicit red-green feedback loop ('Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)'). This matches the anchor-5 example's structure of sequence, validation, and error-recovery loop.

Progressive Disclosure

This is a single-purpose, self-contained skill with no bundle files (no references/, scripts/, or assets/ exist), and everything present belongs inline — a gate procedure, two lookup tables, and pattern templates. Per the rubric's simple-skill guidance, well-organized sections with no need for external references score 5; sections are clearly headed and navigable with no monolithic wall or buried references.

Specificity

The description lists several concrete behaviors — 'requires running verification commands and confirming output before making any success claims' and 'evidence before assertions' — tied to specific contexts (complete, fixed, passing, committing, PRs). It falls below anchor 5 only because it never specifies which kinds of verification (tests, builds, linters) are in scope, leaving a minor coverage gap.

Completeness

Both halves are explicit and concrete: the 'what' ('requires running verification commands and confirming output before making any success claims') and the 'when' ('Use when about to claim work is complete, fixed, or passing, before committing or creating PRs'). This matches the anchor-5 example's structure of concrete capability statement plus explicit trigger phrases; there is no missing half to push it down.

Trigger Term Quality

Natural phrases a user or Claude would actually say are well covered: 'complete', 'fixed', 'passing', 'committing', 'creating PRs', 'verification', 'evidence'. It sits below anchor 5 because common variations like 'done', 'tests pass', 'build succeeds', or 'looks good' are not included.

Distinctiveness Conflict Risk

The trigger is anchored to a distinct moment — the act of claiming completion or committing/PR — which separates it from execution skills like a 'verify' or 'run tests' skill. It is not a 5 because it is a cross-cutting behavioral rule that fires near the end of nearly every task, creating minor overlap with any completion/verification-adjacent skill.