Conciseness

Mostly efficient: every step pairs a short rationale with tight, commented code, and it delegates the full strategies catalog, settings table, and anti-patterns to the reference file. Not 5 because of repeated "Per [hyp-quickstart]" attribution lines (4 occurrences) and a few explanations of things the cited doc already states, e.g. "The `draw()` call requests a value from a strategy; the composite returns the constructed value". Not 3 because the padding is minor and localized, not whole padded sections.

Actionability

Steps 1-8 give copy-paste-ready executable code (install command, property tests, composite strategy, filter/assume, settings, round-trip and metamorphic tests, pytest fixture), plus a concrete CI yaml snippet. Not 5 because Step 9's regression example uses a placeholder `@given(...)` rather than executable code, and the Step 8 fixture body is elided with "# ... setup ..." — minor gaps in an otherwise executable body.

Workflow Clarity

A clear, well-sequenced progression (install -> basic test -> strategies -> composites -> filtering -> settings -> property patterns -> pytest -> CI), with an error-recovery loop: on failure, copy the falsifying example into `@example` to lock in the regression. The "Heavy filtering is a smell - if 90% of generated cases are discarded, redesign the strategy" checkpoint guards the main fragility. Not 5 because there is no explicit validation step for CI integration (e.g., verifying derandomization actually reproduces the failure) and checkpoints are implied rather than enumerated. Not 3 because the sequence is coherent, gaps are minor, and no destructive/batch operations are involved.

Progressive Disclosure

The body is a lean tutorial that keeps only the getting-started subset inline (6 common strategies in Step 3, the 2 most important settings in Step 6) and points to a single real, one-level-deep reference (references/hypothesis-reference.md, verified to exist and contain the full catalog, settings table, anti-patterns, limitations) — signaled at Step 3, Step 6, and again in the References section. Cross-links to sibling skills are grouped for discovery. This matches the 5 anchor: clear overview, well-signaled one-level references, appropriate split. Not 4 because there is no content inlined that clearly belongs in the reference file.

Specificity

Lists multiple concrete actions with the exact API surface: "wires `@given` with `strategies` (`st.integers`, `st.text`, ...)", "uses `assume()` / `.filter()` for preconditions", "configures via `@settings(max_examples=..., deadline=...)", "exploits... automatic shrinking", "Integrates with pytest fixtures + parametrize". Coverage spans authoring, filtering, configuration, shrinking, and test-runner integration — comprehensive. Not 4 because there are no meaningful gaps in capability coverage.

Completeness

Explicitly answers both: what ("Authors property-based tests in Python using Hypothesis... shrinking") and when ("Use when a Python project needs PBT to catch edge cases the example-based tests miss - bug clusters around input ranges / boundary values / interaction between fields"). The when-clause gives concrete trigger conditions, matching the 5 anchor. Not 4 because the trigger is fully specific, not merely present.

Trigger Term Quality

Includes natural phrases users would say: "property-based tests", "Python", "Hypothesis", "pytest", "edge cases", "boundary values", "PBT". Not 5 because it misses common synonyms such as "fuzzing"/"fuzz tests", "generative testing", or "invariant testing" that users often use interchangeably for this skill.

Distinctiveness Conflict Risk

"Python using Hypothesis" plus the library-specific API names carve a clear niche with minimal conflict risk — even sibling PBT skills (fast-check, jqwik, proptest, quickcheck) are for other languages and this description scopes to Python explicitly. Not 4 because the combination of language + library + testing paradigm leaves virtually no ambiguity about which skill applies.