Conciseness

The body is dense and prescriptive, assumes Claude's competence (no git tutorials, no spec background), and the Mindset section adds a genuinely non-obvious insight ("scope consistency drives changelog quality more than type correctness"). However, the 72-character rule is stated three times (Procedure step 4, "Commit Message Format" rules, and its own anti-pattern) and the Anti-Patterns section partially reiterates Procedure rules — minor over-explanation that could be trimmed. Not 5: the repetition is more than zero; not 3: the padding is localized, not "some unnecessary explanation" spread throughout.

Actionability

Fully executable guidance throughout: a concrete format template (`<type>[optional scope]: <description>`), a type table with decision rules for ambiguities ("does the user gain new capability? If yes → feat"), copy-paste validation commands (`echo "feat(auth): add OAuth2 login" | npx commitlint`, `git log --format="%s" HEAD~5..`), and four complete example commit messages covering feature, fix, breaking change, and perf cases. Matches the anchor-5 "fully executable, covers the common cases" standard.

Workflow Clarity

The 7-step Procedure is clearly sequenced with decision rules for common ambiguities, an inline verification heuristic ("If applied, this commit will `<header>`."), and an explicit validation step (step 7: "run `git commit --dry-run` or your local commitlint hook"). It falls short of anchor 5 only because there is no explicit error-recovery loop (e.g., "if commitlint fails, fix the header and re-run") — a minor validation gap that anchor 4 describes. Not 3: validation is present and explicit, not merely implied.

Progressive Disclosure

Both referenced files exist (references/scope-and-strategy.md, references/tooling.md), are exactly one level deep, and are well signaled both inline ("see [Scope Naming and Commit Strategy](references/scope-and-strategy.md)") and in a dedicated References section with per-link descriptions. Bulk detail (tooling setup, scope vocabulary, atomic-commit strategy) is correctly split out, while the inline material (type table, examples, anti-patterns) is the working core the model needs at generation time. A direct match for the anchor-5 "clear overview with well-signaled one-level-deep references" pattern.

Specificity

The description lists multiple concrete actions — "Analyzes diffs or change descriptions", "selects the correct type/scope", "writes an imperative-mood header under 72 characters", "composes optional body and footer sections including breaking-change notation" — with comprehensive coverage and third-person voice. It matches the anchor-5 example's breadth; no meaningful capability gap keeps it at 4.

Completeness

Explicitly answers both questions: "what" via "Generates and formats git commit messages following the Conventional Commits specification… Analyzes diffs… composes optional body and footer sections", and "when" via an explicit "Use when…" clause with concrete trigger phrases. This is a direct match for the anchor-5 example pattern.

Trigger Term Quality

Natural user phrasings are comprehensively covered: "help writing commit messages", "formatting git commits", "write a commit msg for staged changes", "produce a changelog entry", "conventional commits, semantic versioning, or version bumps" — including the colloquial synonym "commit msg". Not 4: no common way a user would phrase this need is missing.

Distinctiveness Conflict Risk

The core triggers ("writing commit messages", "formatting git commits", "conventional commits") form a clear niche, but the standalone triggers "mentions… semantic versioning, or version bumps" would also fire for a user who needs release/versioning tooling rather than commit-message formatting — a minor overlap with closely related skills. Not 5: that neighboring-skill collision risk is real; not 3: the overlap is confined to one adjacent domain.