CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/data-contract-extractor

Use when scoping a new data product or formalizing checks on an existing one. 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.

Quality

95%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

92%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-structured skill body: concrete tables for all five contract sections, a copy-paste YAML output format, a sequenced extraction workflow with an explicit no-fabrication/gap-flagging validation gate, and clean separation of worked examples into a single verified reference file. The only trimmable content is the terminology-provenance aside and the external citation list.

DimensionReasoningScore

Conciseness

The body is dense and information-bearing — field-by-field tables, a complete YAML template, and an anti-patterns table with almost no filler, and it does not explain concepts Claude already knows. Minor over-explanation could be trimmed: the terminology-provenance aside ("'Data contract' is practitioner-emergent terminology (Andrew Jones / Chad Sanderson), not ISTQB-canonical; this skill cites industry-engineering sources") and the References section's ISTQB/ISO citations don't directly advance the task. That places it at the score-4 anchor ('efficient; minor instances of over-explanation that could be trimmed') rather than score 5, and well above score 3.

4 / 5

Actionability

The skill provides a complete, copy-paste-ready YAML output template ("contract_version: 1 ... schema: - name: order_id, type: BIGINT, nullable: false, pk: true ..."), exact field tables for all five contract sections, a concrete gap-question table template, and unambiguous rules like "If only column names are given, flag missing types as gaps; do not guess". This matches the score-5 anchor: fully executable output covering the common cases, not the score-4 anchor with 'minor gaps'.

5 / 5

Workflow Clarity

The 'Step-by-step extraction' section gives a clear 6-step sequence (schema → PII tagging → freshness → volume → distribution → ownership) with per-step source hints, and validation checkpoints are explicit rather than implicit: "Force the data-product author to confirm", "The agent never fabricates contract fields. Every gap becomes an explicit question", and "Until the gaps are filled, the contract is incomplete and the test suite cannot be generated". This matches the score-5 anchor (clear sequence with explicit validation steps and a feedback loop to the human); the destructive/batch cap does not apply since this is documentation extraction, and no destructive or batch operation is involved.

5 / 5

Progressive Disclosure

The body is a well-organized overview (contract structure, output format, workflow, anti-patterns) with the three worked examples correctly split out to a clearly signaled, one-level-deep reference: "Three worked examples (PRD to contract, minimal source with a gap list, and refactor of an existing dataset) are in [references/examples.md](references/examples.md)" — verified to be a real file that back-references SKILL.md without further nesting. This matches the score-5 anchor (clear overview, well-signaled one-level-deep references, appropriately split content) rather than score 4, since the inline YAML is core output format, not content that belongs in a separate file.

5 / 5

Total

19

/

20

Passed

Description

96%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: third-person voice, explicit 'Use when' trigger with two distinct scenarios, concrete input sources, an enumerated output artifact, and named target tools. The only weakness is that listing dbt / Great Expectations / Soda introduces slight trigger overlap with sibling test-suite-generation skills.

DimensionReasoningScore

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" enumerates the concrete inputs, the output artifact with its sub-components, and the target frameworks. It matches the anchor 'lists multiple specific concrete actions; comprehensive coverage' rather than the score-4 anchor, which reserves 'minor gaps in coverage' — nothing material is missing here.

5 / 5

Completeness

Both halves are explicit: the when is "Use when scoping a new data product or formalizing checks on an existing one" and the what is "Reads a data PRD ... and writes a data contract: schema with types, nullability and PII flags ...". This clearly matches the score-5 anchor ('clearly and explicitly answers both what AND when with concrete trigger phrases'), not the score-4 anchor where the 'when' 'could be more explicit or specific'.

5 / 5

Trigger Term Quality

Natural practitioner phrases a user would actually say are present: "data product", "data contract", "data PRD", "freshness SLA", plus the tool names "dbt, Great Expectations or Soda" and input synonyms ("dataset README or lineage doc"). Coverage is comprehensive for this niche with synonym variation; no obviously missing natural term keeps it below the score-5 anchor.

5 / 5

Distinctiveness Conflict Risk

The contract-authoring niche is clear and distinct ("writes a data contract ... for dbt, Great Expectations or Soda"), but naming all three QA tools creates minor overlap risk with closely related sibling test-generation skills (e.g. dbt-testing, soda-checks) — a request to 'write Great Expectations checks' could plausibly match either. This fits the score-4 anchor ('mostly distinct; minor overlap risk with closely related skills') better than score 5, and better than score 3 since the core trigger (authoring a contract from a PRD) would not fire generic skills.

4 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page