data-quality-frameworks
- Use it when:
- You run data pipelines or a warehouse and want bad, missing or stale data caught before it reaches reports or models.
- It does:
- Covers six dimensions of data quality, from completeness to timeliness, tested in three layers: schema, single-column and cross-table tests.
- You get:
- A Great Expectations suite and checkpoint, dbt schema and SQL tests, a data contract in YAML, and a Python pipeline that validates many tables and fails on errors.
- Terms:
- A data contract is a versioned agreement between teams on a table's schema, quality checks and freshness SLA.
- Mind:
- The end of the SKILL.md is garbled by a bad file split; see the note.
Its SKILL.md was cut in the middle of a code block when it was split into two files. The reference file stops partway through a report function; the SKILL.md picks up the rest of that code outside any code block, under a stray "Summary" heading, and the code's closing fence then opens a block that swallows the Best Practices section.
TL;DR
A reference with worked examples, not a step-by-step workflow. It sorts data quality into six dimensions, completeness, uniqueness, validity, accuracy, consistency and timeliness, each with a matching Great Expectations check, and a testing pyramid of schema, column and cross-table tests. Its quick start installs Great Expectations and builds a first expectation suite. The reference file holds six patterns: an orders suite with schema, key, allowed-value, range, freshness, row-count and mean checks; a checkpoint that stores results, updates data docs and posts to Slack on failure; dbt tests for keys, relationships and accepted values, with dbt_utils; custom generic and singular dbt tests in SQL; a data contract in the datacontract.com format with PII flags, SodaCL checks and an SLA; and a Python pipeline that validates several tables and builds a Markdown report. Its rules: test source data before transforming it, add tests as you find issues, alert on failures, version contracts, focus on critical columns, and use dynamic baselines rather than hard-coded thresholds.
Summarizes the skill at 4bde316.
npx skills add https://github.com/wshobson/agents --skill data-quality-frameworks skills.sh pageSource on GitHubAll skills from wshobson/agents
- Total Downloads
- 11,700 on skills.sh, Nov 9, 2026
- Repo stars
- 42,334 wshobson/agents
- First seen
- Jan 20, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 203 |
| Sep 28 | 235 |
| Oct 5 | 295 |
| Oct 12 | 237 |
| Oct 19 | 201 |
| Oct 26 | 207 |
| Nov 2 | 203 |
| Nov 9 | 189 |
| Category |
Find root causes, review code and test what you built. Test-first work, implementation from specs, git hygiene and scope control. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
Knowledge and rules the agent applies while it works: best practices, design principles, API references. |
| Effect |
Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
Everyone else. Unverified vendor claims default to community. |
| Topics | |
| Stack |
SKILL.md
From wshobson/agents at 4bde316. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: data-quality-frameworks
description: Implement data quality validation with Great Expectations, dbt tests, and data contracts. Use when building data quality pipelines, implementing validation rules, or establishing data contracts.Data Quality Frameworks
Production patterns for implementing data quality with Great Expectations, dbt tests, and data contracts to ensure reliable data pipelines.
When to Use This Skill
- Implementing data quality checks in pipelines
- Setting up Great Expectations validation
- Building comprehensive dbt test suites
- Establishing data contracts between teams
- Monitoring data quality metrics
- Automating data validation in CI/CD
Core Concepts
1. Data Quality Dimensions
| Dimension | Description | Example Check |
|---|---|---|
| Completeness | No missing values | expect_column_values_to_not_be_null |
| Uniqueness | No duplicates | expect_column_values_to_be_unique |
| Validity | Values in expected range | expect_column_values_to_be_in_set |
| Accuracy | Data matches reality | Cross-reference validation |
| Consistency | No contradictions | expect_column_pair_values_A_to_be_greater_than_B |
| Timeliness | Data is recent | expect_column_max_to_be_between |
2. Testing Pyramid for Data
/\
/ \ Integration Tests (cross-table)
/────\
/ \ Unit Tests (single column)
/────────\
/ \ Schema Tests (structure)
/────────────\
Quick Start
Great Expectations Setup
# Install
pip install great_expectations
# Initialize project
great_expectations init
# Create datasource
great_expectations datasource new
# great_expectations/checkpoints/daily_validation.yml
import great_expectations as gx
# Create context
context = gx.get_context()
# Create expectation suite
suite = context.add_expectation_suite("orders_suite")
# Add expectations
suite.add_expectation(
gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
suite.add_expectation(
gx.expectations.ExpectColumnValuesToBeUnique(column="order_id")
)
# Validate
results = context.run_checkpoint(checkpoint_name="daily_orders")
Detailed patterns and worked examples
Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient.
Summary: {total_passed}/{total_tables} tables passed")
report.append("")
for table, result in results.items():
status = "✅" if result.passed else "❌"
report.append(f"### {status} {table}")
report.append(f"- Expectations: {result.total_expectations}")
report.append(f"- Failed: {result.failed_expectations}")
if not result.passed:
report.append("- Failed checks:")
for detail in result.details:
if not detail["success"]:
report.append(f" - {detail['expectation']}: {detail['observed_value']}")
report.append("")
return "\n".join(report)
Usage
context = gx.get_context() pipeline = DataQualityPipeline(context)
tables_to_validate = { "orders": "orders_suite", "customers": "customers_suite", "products": "products_suite", }
results = pipeline.run_all(tables_to_validate) report = pipeline.generate_report(results)
Fail pipeline if any table failed
if not all(r.passed for r in results.values()): print(report) raise ValueError("Data quality checks failed!")
## Best Practices
### Do's
- **Test early** - Validate source data before transformations
- **Test incrementally** - Add tests as you find issues
- **Document expectations** - Clear descriptions for each test
- **Alert on failures** - Integrate with monitoring
- **Version contracts** - Track schema changes
### Don'ts
- **Don't test everything** - Focus on critical columns
- **Don't ignore warnings** - They often precede failures
- **Don't skip freshness** - Stale data is bad data
- **Don't hardcode thresholds** - Use dynamic baselines
- **Don't test in isolation** - Test relationships too