Conciseness

The ~100-line body is dense with project-specific rules, exact entry formats, and commands, with zero explanation of concepts Claude already knows (no 'what git is' padding). The 'Short version' bullets under Convex projects are a deliberate summary of the reference file, not over-explanation, so anchor 5 fits rather than 4.

Actionability

Concrete, copy-paste-ready guidance throughout: exact commands ('git rev-parse --show-toplevel', 'git log --date=short -n 20'), exact completed-entry syntax for task.md, a worked files.md example, good/bad changelog phrasing ('Uploads over 5 MB now show a progress bar' beats 'refactored upload hook'), and a report-format template. As an instruction-only skill its guidance is fully executable, matching anchor 5.

Workflow Clarity

The 'Run the sync' section gives a clear 7-step sequence with explicit validation checkpoints: idempotency (step 5, 'If nothing new landed ... change nothing and say so'), a secrets/redaction scan before saving (step 6), and verification gating for Completed items ('If the PRD lists a check that has not run, leave it In Progress and say which check is pending'). Because this batch-edit workflow does include validation and error-recovery rules, the destructive/batch cap does not apply and anchor 5 fits.

Progressive Disclosure

The body is a well-organized overview with two clearly signaled, one-level-deep references — [references/evidence-rules.md] and [references/convex-detection.md], both verified to exist — each linked at the point of use with its purpose stated. Core rules stay inline; evidence-strength tables and the Convex detection matrix are correctly split out, matching anchor 5.

Specificity

The description names the three target files (task.md, changelog.md, files.md) and multiple concrete actions — 'Brings ... back in sync with what the code says shipped', 'Reads git history and the working tree, never memory', 'refuses to log features it cannot see in source' — all in third person, with comprehensive coverage for the domain. It is not 4 because no meaningful action in the skill's scope is left out.

Completeness

It explicitly answers both what ('Brings task.md, changelog.md, and files.md back in sync with what the code says shipped') and when ('Use when a feature or fix lands, when the user says "update the docs" ... or when task.md and the code disagree') with concrete trigger phrases. Anchor 5 matches exactly; the when-clause is explicit, not implied, so it is not 4.

Trigger Term Quality

Natural user phrasings ('update the docs', 'sync changelog', 'update files.md', '@update'), a landing event ('when a feature or fix lands'), and a disagreement condition ('task.md and the code disagree') give comprehensive trigger coverage including file extensions and an @-command. It is not 4 because no common way a user would ask for this is missing.

Distinctiveness Conflict Risk

A clear niche — evidence-based syncing of three named project-doc files with git as the only source of truth — with distinct triggers (the file names themselves). Only 'update the docs' is mildly generic, but the named files and the disagreement condition keep conflict risk minimal, fitting anchor 5 rather than 4.