Conciseness

The body is mostly efficient routing content, but includes unnecessary motivational padding: "cuts through the academic jargon... No category theory. No abstract nonsense. Just patterns that make your code better in practice", "It is not a religion or an end in itself", and the Kyle Simpson / Functional-Light citation repeated in three separate places (intro, modes table, Golden Rule section) with the readability principle restated multiple times. This is more than the 'minor instances' of anchor 4, but the body never explains concepts Claude already knows, so it sits above anchor 2.

Actionability

Guidance is concrete and executable for a directive/routing skill: the modes table maps situations to specific load commands ("Load `references/80-20-patterns.md`"), the Golden Rule is an explicit decision rule, and the phase gates and quality checklist give actionable criteria. The minor gap keeping it from 5 is that no pattern is demonstrated inline — not even a one-line before/after — so all executable FP guidance is deferred to the reference files.

Workflow Clarity

The phase gates ("Core patterns → Apply", "Apply a pattern → Restrain", "Any change → Readability") are explicit validation checkpoints in sequence, the quality checklist provides verification criteria, and "Did this help?" plus the issue-filing path form a feedback loop. This matches anchor 5's explicit validation steps, checklists, and feedback loops; the skill involves no destructive or batch operations, so no cap applies.

Progressive Disclosure

Verified against the actual bundle: all six paths cited in the body exist in references/ (80-20-patterns.md, when-not-to-use.md, quick-wins.md, common-refactors.md, readability-rule.md, limitations.md), and the reference files contain no nested references, so everything is one level deep. The body is a concise overview whose modes table gives clear per-topic navigation, matching anchor 5.

Specificity

"Apply 80/20 fp-ts in TypeScript and skip FP when it hurts readability" names the domain and two concrete actions (apply the pragmatic fp-ts subset, skip FP when it hurts readability), matching the anchor for 1-2 concrete actions. It stays at 3 rather than 4 because the description does not list several specific actions — the five patterns and before/after refactors are only named indirectly via "pipe, Option, or Either" in the trigger clause.

Completeness

The description explicitly answers both questions: what ("Apply 80/20 fp-ts in TypeScript and skip FP when it hurts readability") and when, with concrete trigger phrases ("Use when choosing pipe, Option, or Either, or deciding whether FP helps the code"). This matches the anchor-5 pattern and exceeds anchor 4, whose example 'when' clause ("Use when working with PDF files") is generic by comparison.

Trigger Term Quality

"Use when choosing pipe, Option, or Either, or deciding whether FP helps the code" includes the natural terms an fp-ts user would say (pipe, Option, Either, fp-ts, TypeScript), giving good keyword coverage. It falls short of 5 because common synonyms are missing: "functional programming" is only abbreviated as "FP", and variants like Result, TaskEither, or "monadic error handling" are absent.

Distinctiveness Conflict Risk

It carves out a clear niche (pragmatic fp-ts usage in TypeScript) and explicitly disambiguates from a sibling skill: "It does not apply named community styles (that's `code-style-patterns`)". This active boundary marking gives minimal conflict risk, matching anchor 5 rather than anchor 4's 'minor overlap risk'.