CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/data-contract-extractor

Reads a data-product spec (data PRD, dataset README, lineage doc) and emits a structured data contract - schema (columns + types + nullability + PII flags), freshness SLA, volume bounds, distribution invariants, and ownership. The contract is consumable by data-quality tools such as dbt tests, Great Expectations, or Soda checks as their assertion baseline. Use when scoping a new data product or formalizing assertions on an existing one.

75

Quality

94%

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

85%

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

The body is highly actionable and well-structured, with a complete YAML output template, concrete per-field tables, a sequenced extraction workflow, and an explicit gap-flagging checkpoint. Its only weakness is mild conciseness loss from terminology/citation commentary in the Overview and References sections.

Suggestions

Trim the Overview's origin commentary ('practitioner-emergent terminology (Andrew Jones / Chad Sanderman), not ISTQB-canonical; this skill cites industry-engineering sources') - this is context Claude does not need to produce a contract.

Condense the References section: drop the meta-commentary around ISTQB/ISO citations and keep only the concrete pointer to the qa-data-quality plugin and data-quality-conventions skill that the contract actually depends on.

DimensionReasoningScore

Conciseness

Mostly efficient (tables, a complete YAML example, concrete steps), but the Overview and References carry explanatory padding Claude does not need, e.g. 'Data contract is practitioner-emergent terminology (Andrew Jones / Chad Sanderson), not ISTQB-canonical; this skill cites industry-engineering sources' and the ISTQB/ISO citation commentary. Not level 3 because some tokens do not earn their place; not level 1 because the bulk is concrete and non-padded.

2 / 3

Actionability

Provides a fully executable, copy-paste-ready YAML output format plus per-column field tables with exact values and concrete extraction steps, matching the 'fully executable, copy-paste ready' anchor.

3 / 3

Workflow Clarity

A clearly sequenced 6-step extraction process paired with an explicit gap-flagging checkpoint ('Until the gaps are filled, the contract is incomplete and the test suite cannot be generated') forms a validation feedback loop, meeting the anchor for explicit checkpoints and error-recovery guidance.

3 / 3

Progressive Disclosure

The body is well-sectioned with a clearly signaled, verified one-level-deep reference to references/examples.md under '## Examples'; worked examples are appropriately split out, giving easy navigation rather than a monolithic wall of text.

3 / 3

Total

11

/

12

Passed

Description

100%

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

The description is strong across all dimensions: it states concrete capabilities, includes a clear 'Use when' trigger, and occupies a distinctive niche. It uses correct third-person voice. No suggestions needed.

DimensionReasoningScore

Specificity

Lists multiple concrete actions and outputs: 'emits a structured data contract - schema (columns + types + nullability + PII flags), freshness SLA, volume bounds, distribution invariants, and ownership', matching the 'lists multiple specific concrete actions' anchor rather than the partial level 2.

3 / 3

Completeness

Explicitly answers both what ('Reads a data-product spec... and emits a structured data contract') and when ('Use when scoping a new data product or formalizing assertions on an existing one'), meeting the explicit-trigger anchor; not level 2 because the 'when' is present and explicit.

3 / 3

Trigger Term Quality

Includes natural terms a data engineer would say - 'data PRD', 'data-product spec', 'data contract', 'dbt tests', 'Great Expectations', 'Soda checks' - giving good coverage of natural trigger language rather than only jargon.

3 / 3

Distinctiveness Conflict Risk

The narrow niche of 'data contract' generation for dbt/GX/Soda assertion baselines is clearly distinct from generic data or document skills and unlikely to trigger the wrong skill.

3 / 3

Total

12

/

12

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

Table of Contents

DiscoveryImplementationValidation