Conciseness

The body is dense and lean: every section carries domain-specific guidance (boundary decision order, type-world distinctions, query requirements) and assumes Claude's competence — no basic concepts are re-explained. Not a 4 because there is no identifiable padding or over-explanation to trim; tables and terse imperative lists carry the payload.

Actionability

Guidance is highly concrete — exact file paths ('crates/biome_js_type_info/src/type_data.rs'), specific API names ('domains: &[RuleDomain::Types]', 'Typed<N>', 'infer_module_types'), numbered step sequences, and an explicit result-semantics table. It is not a 5 because some execution detail is delegated to the external CONTRIBUTING.md guides rather than stated, and a few requirements ('have correctness and selective-execution tests') state the expectation without showing how; it is well above a 3 since the common cases (adding a lint rule, adding a raw representation, adding a query) each get specific, followable steps.

Workflow Clarity

Multi-step processes are explicitly sequenced ('Changing Raw Inference' steps 1–5, lint-rule steps 1–5), a decision order with early-return checkpoints governs boundary selection, testing guidance maps each change type to its verification boundary, and a final Review Checklist validates the whole change. Uncertainty-preservation rules ('Unknown or indeterminate information is not a negative result') act as explicit error-handling checkpoints, so this is not a 4.

Progressive Disclosure

The body is a well-organized overview: a task-to-guide table routes to exactly two one-level-deep external guides, deep architecture detail (traits, registration, snapshot mechanics) is deferred to those guides and other skills ('Load testing-codegen'), and the body itself stays at decision-level altitude with clear section headers. Not a 4 because no content that belongs in a separate reference file is inlined and every reference is clearly signaled.

Specificity

The description enumerates many concrete capability areas — 'type-aware lint rules, raw collection or inferred representations, analyzer requests, tracked queries, import or cycle resolution, profiling, and Salsa invalidation tests' — giving comprehensive, non-abstract coverage of the skill's scope. It is not a 4 because the action list is extensive and each item is a distinct, specific task rather than a minor-gap partial list.

Completeness

Both questions are answered explicitly: what it does ('Biome's Salsa-backed JavaScript and TypeScript inference, including type-aware lint rules...') and when ('Use this skill when working on...'), plus explicit negative triggers ('Do not use for standalone CSS/HTML module-graph data... or for ordinary semantic binding analysis'). Concrete trigger phrases make the when-clause fully explicit.

Trigger Term Quality

Good natural-term coverage for the domain: 'type-aware lint rules', 'type inference', 'profiling', 'invalidation tests', 'JS/TS'. It is not a 5 because a few natural variations users might say are absent (e.g., 'type checking', 'inferred types', 'type safety'), and the terms lean technical; not a 3 because several genuinely natural phrases for this codebase are present.

Distinctiveness Conflict Risk

A clear niche — Salsa-backed JS/TS inference in the Biome codebase — with explicit exclusions separating it from neighboring skills (CSS/HTML module-graph work, semantic binding analysis). Distinct triggers and stated boundaries minimize the risk of firing for the wrong skill.