Conciseness

Mostly dense and framework-specific (install commands, "100 generated cases", failure output format, anti-patterns table), but contains trimmable material: the Overview quotes fast-check's self-description, the predicate bullet list ("true → the property holds. false → the property fails") restates basic property-test semantics, and the "fc.assert(fc.property(<arbitraries...>" shape, the runner-agnostic claim, and reference links each appear two-to-three times. These are minor instances of over-explanation, so above the "mostly efficient but could be tightened" anchor but short of "every token earns its place".

Actionability

Copy-paste-ready throughout: "npm install fast-check --save-dev" (plus yarn/pnpm), the complete Mocha "contains" example, a runnable Vitest round-trip test, a composite fc.record payload, and the async form "await fc.assert(fc.asyncProperty(...))". Common cases (basic property, composite inputs, async, failure/replay) are all covered; the "// Jest / Vitest example" label over a vitest-only import is a trivial nit that keeps it at, not below, the fully-executable anchor.

Workflow Clarity

The 8-step "How to use" is clearly sequenced with an explicit validation feedback loop at step 7: "re-run the property and confirm it passes... replay the failing seed to confirm the counterexample is gone; if it still fails, the fix is incomplete or the property itself is wrong - correct and re-run". Step 6 handles error recovery via seed replay, and the worked example demonstrates the failure→shrink→replay→fix cycle concretely. Not 4: checkpoints and recovery loops are explicit, not merely "most" present.

Progressive Disclosure

The body is an overview that delegates cleanly: "Full catalog and combinator patterns: references/arbitraries.md", shrinking/replay detail, and stateful/async patterns each go to a separate, verified one-level-deep file (all three paths exist in the bundle, none references another). Each link is clearly signaled with a purpose statement and re-listed with annotations in the References section, so navigation is easy — matching the clear-overview anchor rather than the "minor organization gaps" one.

Specificity

Lists concrete items — "fc.assert and fc.property, arbitraries and composite inputs, map, chain and filter, shrinking and seeds, with Jest, Vitest or Mocha" — but frames them as a feature catalog rather than actions, leaving the core capability (writing/running property tests) implicit. Not 5 because no explicit action verbs like the anchor's "Extract... fill... merge"; not 3 because every listed term is concrete and domain coverage is broad.

Completeness

Explicit "when" — "Use whenever the task mentions property-based, generative or invariant tests in JavaScript or TypeScript (fast-check)" — paired with an explicit "what" enumerating fc.assert/fc.property, arbitraries, map/chain/filter, shrinking and seeds. Not 4 because the when-clause is maximally explicit with concrete trigger phrases, exceeding that anchor's "could be more explicit" caveat.

Trigger Term Quality

Covers the natural phrasings a user would say — "property-based, generative or invariant tests", "fast-check", "shrinking and seeds", "Jest, Vitest or Mocha" — including synonyms (property-based/generative/invariant) and specific API tokens (fc.assert, fc.property). Only trivial omissions (e.g. "PBT", "QuickCheck-style"), matching the comprehensive-synonyms anchor.

Distinctiveness Conflict Risk

Clear niche — JS/TS property-based testing with fast-check — with distinct trigger phrases; runner names appear as integration context, not standalone triggers. Fits "clear niche with distinct triggers; minimal conflict risk"; only negligible overlap with generic Jest/Vitest skills.