Conciseness

The body is mostly terse imperatives rather than padded prose, but contains near-duplicate bullets ("Use meaningful, descriptive names" vs "Use descriptive names"; the two early-return bullets; the 'When to Optimize' list restating "only after measurable bottlenecks" twice) and restates basics Claude already knows (single responsibility, magic numbers, DRY). It fits anchor 3 ('mostly efficient but could be tightened'): above 2 because there is little explanatory padding, below 4 because the duplication and well-known content could be trimmed.

Actionability

Some guidance is concretely decidable ("single-letter names are acceptable only for loop counters or well-known conventions (i, j, x, y)"; "Mask or exclude passwords, tokens, PII from logs"), but many principles are abstract directives with no examples or thresholds ("Depend on abstractions, not concrete implementations"; "Functions should have a single level of abstraction"), and the body contains no code examples. This matches anchor 3 ('some concrete guidance but incomplete') rather than 4, where most guidance would be executable with only minor gaps.

Workflow Clarity

This is a principles catalog, not a multi-step procedure, so a rigid sequence does not apply; the Refactoring Approach section does give a sequenced micro-workflow with verification ("Run tests after each change", "Maintain working state: Keep tests passing"), and sections are organized by concern. It sits at 4 rather than 5 because there is no explicit guidance on how to order or apply the principles across a task, and 4 rather than 3 because the sequences that do exist include their verification steps.

Progressive Disclosure

Both bundle files exist and are well-signaled with one-level-deep references and explicit load conditions ("For concrete detection patterns used by security review, see references/security-checks.md"; "read when implementing, reviewing, or fixing React/TypeScript code"), with language-agnostic core kept inline and domain specifics split out. It is 4 rather than 5 because the ~165-line body still carries substantial detail (e.g. the full Reference Representativeness and Commenting sections) that could arguably live in references, leaving minor organization gaps.

Specificity

"Language-agnostic coding principles for maintainability, readability, and quality" names the domain plus its focus areas, but describes no concrete capabilities or actions (compare "Extracts text and tables from PDF files, fill forms"), matching the anchor 'names domain and 1-2 concrete actions'. It is above 2 because the three named quality attributes give more substance than a purely generic phrase, but below 4 because there are no enumerated actions at all.

Completeness

The description explicitly answers both: what ("Language-agnostic coding principles for maintainability, readability, and quality") and when ("Use when implementing features, refactoring code, or reviewing code quality") with three concrete trigger phrases, matching the top anchor. It is not 4 because the 'when' clause is already explicit and multi-trigger, not merely adequate.

Trigger Term Quality

"implementing features", "refactoring code", "reviewing code quality" are natural phrases users would say when needing this skill. Below 5 because common variations like "code review", "clean code", "best practices", or specific languages are missing.

Distinctiveness Conflict Risk

The trigger "implementing features" is broad enough to fire on nearly any coding task, and the skill overlaps with dedicated code-review or refactoring skills. It is somewhat specific (quality principles, not general help) but overlaps with similar skills, matching anchor 3; not 4 because "implementing features" creates real overlap risk.