Conciseness

The ~50-line body is lean and dense: a two-tier storage table, a single-source-of-truth rule, a numbered protocol, and exact output conventions, with every token carrying project-specific rules Claude could not infer. There is no padding and no explanation of concepts Claude already knows, matching the score-5 anchor.

Actionability

The guidance is concrete and executable: exact paths ('docs/project-context/external-resources.md'), fixed heading text 'External Resources Used' with per-document heading levels (h2 in UI Spec, h3 in Design Doc), a numbered reference protocol, and copy-paste templates delegated to references/template.md. It sits just below the score-5 anchor because no worked example of a completed record appears in the body itself — the example is delegated to the reference file.

Workflow Clarity

The Reference Protocol is a clearly sequenced three-step process with an explicit failure checkpoint ('When the file is absent or the resource is unreachable, continue from governing and repository evidence. Each consumer records the limitation in its applicable output'), and the capture workflow in references/hearing.md adds correction and fallback behavior. This is not a destructive or batch skill, so no cap applies; minor validation gaps (e.g., no explicit re-check after an environment change) keep it at score 4 rather than 5.

Progressive Disclosure

The body is a well-sectioned overview with six references, each labeled with its purpose ('Decision-specific capture and storage', 'Frontend domain axes', 'Project-tier and feature-tier structure templates'), all of which exist and contain the promised material. References are one level deep with no further nesting, matching the score-5 anchor of a clear overview with well-signaled, appropriately split content.

Specificity

The description names one core concrete action ('Records where resources outside the repository live ... and how design, implementation, and verification reach them') with a comprehensive enumeration of specific resource types (design source, design system, API schema, IaC source, secret store). It falls short of the score-5 anchor, which requires multiple distinct actions (e.g., extract, fill, merge, convert), but goes well beyond the score-3 anchor's limited 1-2 action coverage.

Completeness

It explicitly answers both 'what' (records where external resources live and how design, implementation, and verification reach them) and 'when' ('Use when work depends on an external resource, or when the user mentions design source, design system, API schema, IaC source, secret store, or canonical source') with concrete trigger phrases, matching the score-5 anchor. It clearly exceeds score 4, whose 'when' clause is less explicitly enumerated.

Trigger Term Quality

Trigger terms like 'design source', 'design system', 'API schema', 'IaC source', 'secret store', and 'canonical source' are natural phrases users in this domain would say, giving good keyword coverage. A few natural terms are missing — notably concrete tool or format synonyms (e.g., Figma, OpenAPI, Terraform) a user might mention instead of the abstract category names.

Distinctiveness Conflict Risk

The niche — recording access methods for external resources — is distinct, and the specific trigger terms (secret store, IaC source, API schema) reduce confusion risk. However, the broad trigger 'work depends on an external resource' leaves minor overlap risk with closely related design, frontend, or API-contract skills, keeping it below the minimal-conflict score-5 anchor.