Conciseness

The body is efficient and assumes competence (no tutorial padding about what TypeScript is), and the Anti-Patterns use a tight WHY/BAD/GOOD format. It is not a 5 because the 'When to Apply' bullet list and the 'Use When' question list substantially restate the same triggers, which could be merged or trimmed.

Actionability

Concrete, executable content is present: `npx tsc --noEmit` commands and complete, runnable TypeScript snippets in every anti-pattern (e.g. `type PropType<T, K extends keyof T> = T extends { [P in K]: infer V } ? V : never;`). Not a 5 because the body contains only anti-pattern examples and verification commands — no short positive example of the core derivations (e.g. a mapped type or an `infer` extraction) is shown inline, leaving minor gaps for the most common cases.

Workflow Clarity

For a reference-style knowledge skill the guidance is unambiguous: 'model the problem in types before reaching for a runtime check' plus explicit verification commands (`npx tsc --noEmit` and single-file variant) act as validation checkpoints. Not a 5 because the type-check step is never explicitly sequenced into the guidance (no 'write the type, then run the check, fix if it fails' loop), though nothing here is risky, batch, or destructive so no cap applies.

Progressive Disclosure

The body is a lean overview and all detail lives in 8 real, one-level-deep reference files, each clearly signaled in a table with a 'Covers' column (all paths verified to exist, and none of the reference files nest further references). Scoped sections (In/Out of Scope, When NOT to Use) plus external handbook links make navigation easy — this matches the top anchor.

Specificity

The description enumerates concrete, comprehensive capabilities: "union and intersection types, conditional types with `infer`, mapped types, template literal types, generics and their constraints, index signatures, type assertions, and extracting types from other types (return types, array elements, promise results)" — no vague filler. Not score 4 because coverage spans the full domain with specific sub-examples (e.g. return types, array elements, promise results) rather than leaving minor gaps.

Completeness

It explicitly answers both questions: 'what' is the enumerated list of type-system mechanics, and 'when' is the concrete "Use when designing a complex generic, modeling a type that transforms based on another type, extracting a type... or deciding between a type assertion and a real narrowing check." This matches the score-5 anchor with concrete trigger phrases for both.

Trigger Term Quality

The 'Use when' clause uses natural phrases a TypeScript user would actually say: "designing a complex generic", "extracting a type from a function or structure with `infer`", "deciding between a type assertion and a real narrowing check", plus domain keywords like mapped types and template literals. Not score 4 because synonyms and variations (e.g. "transforms based on another type" alongside 'conditional type') are covered comprehensively.

Distinctiveness Conflict Risk

The niche is clear — compile-time, type-level TypeScript mechanics — but the trigger "deciding between a type assertion and a real narrowing check" overlaps with the domain of a sibling runtime-narrowing/type-guards skill. Not score 5 because that boundary is drawn only in the body's Scope section, not in the description itself; not score 3 because the type-level framing keeps it mostly distinct.