Conciseness

Every sentence carries load: the ~150-line body covers when to run the check ("before review and in CI"), both invocation modes, the measured set ("`AGENTS.md`, `CLAUDE.md`, `GEMINI.md` and `SKILL.md`, at the root and at any depth, and no other file"), failure semantics, and remediation — with zero padding and no explanation of concepts Claude already knows. Matches the anchor 'lean and efficient; assumes Claude's competence; every token earns its place'.

Actionability

The body gives two copy-paste-ready executable commands ("doc-limits" and "doc-limits --staged") plus a concrete pointer for the rest ("Flags, settings and exit codes are in `doc-limits --help`"), matching 'mostly executable guidance; concrete code or commands with minor gaps'. Not 5 because the add/tune use cases promised by the description (a class entry, an excludes row) have no inline example — both are one hop away in references/policy.md; not 3 because the guidance given is concrete and executable, not high-level hints or pseudocode.

Workflow Clarity

This is a simple single-action skill and the action is unambiguous: when to run it ("before review and in CI", and which commit-guards chains use staged mode, including why — "at push the index is held equal to HEAD first, so that mode measures the tree being pushed"), how to run it (both commands), what failure means ("A document over its limit fails the check"), and the remediation loop ("A document that must stay whole gets a row in the configured excludes file with its reason"). The check is itself the validation step, so the batch-operation validation cap does not apply.

Progressive Disclosure

Verified against the actual bundle: references/policy.md exists and contains exactly the promised material (Path classes, exclusion list format), scripts/doc-limits is a real executable, and the body's links ([references/policy.md § Path classes](references/policy.md#path-classes)) are one level deep, well-signaled with a section anchor, with all detail (class format, exclusion rows, flags, exit codes) appropriately split out. Matches 'clear overview with well-signaled one-level-deep references; content appropriately split; easy navigation'.

Specificity

"Load to add, tune, or debug document byte ceilings and DOC_LIMITS_* settings" lists three concrete actions (add, tune, debug) applied to a specifically named object ("document byte ceilings", "DOC_LIMITS_* settings"), matching the anchor for several specific actions with minor gaps in coverage. Not 5 because coverage is not comprehensive (no mention of the excludes file, class configuration, or CI usage); not 3 because the actions and domain are more concrete than 1-2 generic actions.

Completeness

The 'what' is clear (add, tune, or debug byte ceilings and DOC_LIMITS_* settings) and the 'when' is given by the explicit purpose clause "Load to add, tune, or debug...", which is equivalent trigger guidance naming the triggering tasks. Not 5 because the when-clause lacks concrete natural trigger phrases (no file names or common user phrasings); not 3 because the trigger is directly stated, not merely weakly implied.

Trigger Term Quality

Relevant keywords are present ("document", "byte ceilings", "debug", "DOC_LIMITS_* settings") but common variations users would naturally say are missing — notably "limit(s)" (the skill's own name is doc-limits yet the description never says "limit"), "size", "too large", and the affected file names (CLAUDE.md, SKILL.md). Matches the anchor 'some relevant keywords but missing common variations or synonyms'; not 4 because the natural-phrase surface is narrow, and not 2 because the keywords present are domain-specific rather than generic.

Distinctiveness Conflict Risk

"document byte ceilings and DOC_LIMITS_* settings" occupies a clear niche: the DOC_LIMITS_* namespace is a unique identifier and 'byte ceilings' scopes 'document' away from document-processing skills, so the risk of triggering the wrong skill is minimal. Not 4 because no closely related skill would plausibly compete for these triggers.