Conciseness

The 34-line body is lean with zero padding: it never explains concepts Claude already knows, and every section (Why, The pattern, Applications, The tests) earns its place — 'Scattered validation is noisy, redundant, and gives a false sense of safety' justifies the rule in one sentence rather than lecturing.

Actionability

Concrete directives like 'Validate config at parse time (the boundary), not inside business logic', 'Store raw data at boundaries; parse lazily at use-site', and the two decision tests give mostly executable guidance for an instruction-only skill. The minor gap is the absence of a worked before/after example (e.g., a boundary parse function vs. a redundant internal nil check) that would make the boundary line unmistakable.

Workflow Clarity

This is a simple, single-purpose principle skill under 50 lines with no multi-step process; the single action (place guards at boundaries, extract pure logic) is unambiguous, and the closing tests ('Is this data crossing a system boundary right now?', 'Can this be a pure function that the shell just calls?') function as explicit decision checkpoints. No destructive or batch operations exist to require validation loops.

Progressive Disclosure

The skill is under 50 lines with no need for external references (no references/, scripts/, or assets/ bundles exist), and the body is organized into clearly labeled sections (pattern, applications grouped by validation/error handling and code organization, tests), matching the simple-skill exception for a top score.

Specificity

It lists several specific directives — 'Concentrate guards at system boundaries (CLI, config, network, external APIs)', 'trust internal types', 'keep business logic in pure functions' — with only minor gaps. Not 5 because the boundary actions themselves (validate, return errors, handle defensively) are left to the body rather than enumerated here; clearly above the 1-2-actions level 3 anchor.

Completeness

It explicitly answers both: what ('Concentrate guards at system boundaries... trust internal types and keep business logic in pure functions') and when ('Apply when wiring validation, error handling, or framework adapters') with concrete trigger phrases. Matches the level 5 anchor; the when-clause is already specific, so level 4's 'when could be more explicit' does not apply.

Trigger Term Quality

Natural trigger terms are well covered: 'validation', 'error handling', 'framework adapters', 'CLI', 'config', 'network', 'external APIs'. Not 5 because common phrasings users would actually say — 'input validation', 'defensive programming', 'sanitize input', 'adapters' — are missing; well above level 3's 'missing common variations'.

Distinctiveness Conflict Risk

The boundary-discipline framing ('guards at system boundaries (CLI, config, network, external APIs)') carves a clear niche with distinct triggers. Not 5 because 'wiring validation, error handling' is a broad trigger surface with minor overlap risk against general validation/error-handling guidance; comfortably above level 3's 'could still overlap with similar skills'.