Conciseness

The body is dense and earns its tokens — field tables, a complete YAML template, and tight extraction steps with no explanation of concepts Claude already knows. Not 5: a few meta sentences could be trimmed, e.g. "'Data contract' is practitioner-emergent terminology (Andrew Jones / Chad Sanderson), not ISTQB-canonical; this skill cites industry-engineering sources" and the References section's citation-practice notes ("cite by stable ID; paywalled at iso.org"), which don't advance the extraction task.

Actionability

The "Output format" section is a complete, copy-paste-ready YAML contract covering the common case (orders dataset with schema, PII tags, freshness, volume, distribution, ownership), and the step-by-step extraction gives concrete search targets ("look for 'updated daily' / 'real-time' / '<X minutes'") plus a ready-made gap-table template. Not 4: the output template is complete and directly consumable by the named tools, with no missing key details.

Workflow Clarity

The six numbered extraction steps are clearly sequenced, and gap-flagging is an explicit checkpoint ("The agent never fabricates contract fields. Every gap becomes an explicit question"; "Until the gaps are filled... the test suite cannot be generated"). Not 5: the end-to-end flow (read → extract → flag gaps → emit YAML → hand off to sibling skills) must be assembled across sections rather than presented as one ordered workflow, and there is no output-validation step (e.g. confirming the emitted YAML is well-formed and every section present). Not 3: gap-flagging with the human-input-required table is a strong explicit checkpoint, and this is not a destructive/batch operation so no cap applies.

Progressive Disclosure

The body is a clear overview with the core contract structure and output template appropriately inline, and worked examples correctly split into references/examples.md — verified to exist (60 lines, one level deep, no nested references). The single reference is well signaled under "## Examples" with its contents described ("Three worked examples (PRD to contract, minimal source with a gap list, and refactor of an existing dataset)"). Not 4: there are no organization gaps — every section is discoverable and nothing that belongs in a separate file is inlined.

Specificity

"Reads a data PRD, dataset README or lineage doc and writes a data contract: schema with types, nullability and PII flags, freshness SLA, volume bounds, distribution rules and owner, for dbt, Great Expectations or Soda" lists multiple concrete actions with comprehensive coverage across input sources, output fields, and target tools. Not 4: coverage has no notable gaps — inputs, outputs, and downstream consumers are all enumerated.

Completeness

Explicitly answers both parts: "Use when scoping a new data product or formalizing checks on an existing one" (when, with concrete triggers) and the what — reads named source docs and writes a contract with enumerated field groups for named tools. Third-person voice ("Reads", "writes") is used. Matches the anchor-5 example structure of concrete what + explicit when.

Trigger Term Quality

Natural practitioner terms are comprehensively covered: "data PRD", "dataset README", "lineage doc" (source synonyms), "data contract", "dbt", "Great Expectations", "Soda" (tool names, the domain's equivalent of file extensions), plus "PII", "freshness SLA". Not 4: the synonym coverage across both source-document types and tool names leaves no commonly used trigger phrase missing.

Distinctiveness Conflict Risk

The contract-authoring niche is clear ("writes a data contract" from a PRD/README/lineage doc), but the phrases "formalizing checks" and the tool names "dbt, Great Expectations or Soda" overlap with closely related sibling test-suite-generation skills. Not 5: a user asking to "write dbt tests" or "add Great Expectations checks" could plausibly trigger this skill; not 3: the PRD-to-contract extraction trigger is well differentiated from generic data-quality work.