agentleFS
karim-bhalwanikarim-bhalwani/agent-skills-collection/skills/data-quality-frameworks/SKILL.md

data-quality-frameworks

Skill0 starsChanged 10 months agoMITView on GitHub

Specialist in data quality validation frameworks—Great Expectations, dbt tests, data contracts. Builds comprehensive data quality gates into pipelines for reliability and trust.

5 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test coverage best practices

    line 69
  2. Distinctive:

    Silver (Business Rules): Test foreign keys, categorical values, ranges

    line 113
  3. Distinctive:

    Gold (Aggregations): Verify aggregation logic, metric calculations

    line 114

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Data Quality Frameworks

Expert in embedding quality validation into data pipelines as a dependency, not an afterthought.

When to Use This Skill

Use when:

  • Building comprehensive data quality validation into pipelines
  • Setting up Great Expectations suites and automated checkpoints
  • Creating dbt test suites (schema tests, relationship tests, custom tests)
  • Establishing data contracts between producer and consumer teams
  • Monitoring data quality metrics, SLAs, and anomalies
  • Debugging data quality failures or regressions
  • Implementing layer-based validation (Bronze schema, Silver business rules, Gold aggregations)
  • Blocking bad data from proceeding downstream

Core Capabilities

  1. Great Expectations - Build expectation suites, checkpoints, automated validation
  2. dbt Testing - Schema, relationship, and custom test strategies
  3. Data Contracts - Producer/consumer agreements (ODCS, datacontract-cli)
  4. Quality Monitoring - Continuous validation, metrics tracking, alerting
  5. Debugging - Root-cause analysis of data quality anomalies
  6. Layer-Based Validation - Schema (Bronze), rules (Silver), aggregation checks (Gold)

Framework References

For detailed implementation guidance, see:

Great Expectations

Use when: Building GE validation suites and checkpoints

Covers:

  • Building comprehensive expectation suites
  • Checkpoint configuration and automation
  • Running validations and handling failures
  • Integration patterns and alerting

dbt Testing

Use when: Creating dbt test suites

Covers:

  • Schema tests (unique, not_null, accepted_values, relationships)
  • Custom generic tests (reusable across models)
  • Singular tests (specific business rules)
  • Test coverage best practices

Data Contracts

Use when: Establishing producer/consumer agreements

Covers:

  • Data contract specification format
  • Schema definitions with PII classification
  • Quality expectations and SLA definitions
  • Contract versioning and evolution
  • Validation against contracts

Automated Quality Pipeline

Use when: Orchestrating end-to-end quality validation

Covers:

  • Building orchestrated quality pipelines
  • Multi-table validation workflows
  • Quality reporting and metrics
  • Integration with Airflow/orchestrators
  • Blocking pipelines on failures

Quick Decision Guide

GoalReference
Build GE validation suiteGreat Expectations
Add dbt tests to modelsdbt Testing
Define producer/consumer contractData Contracts
Orchestrate multi-table validationAutomated Quality Pipeline

Quality Strategy

Layer-Based Testing

  • Bronze (Schema): Validate schema, data types, null constraints
  • Silver (Business Rules): Test foreign keys, categorical values, ranges
  • Gold (Aggregations): Verify aggregation logic, metric calculations

Test Pyramid

  • Most tests: Single column validations (fast, focused)
  • Fewer tests: Cross-table relationships (slower, broader)
  • Blocking vs Warning: Block bad data; warn on minor issues

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

Common Pitfalls & Fixes

PitfallFix
Testing only prodRun tests on dev first: dbt test --target dev
Generic thresholdsTailor tests to data characteristics
No alertingIntegrate with monitoring; block failures
Outdated expectationsReview and refresh expectations quarterly
Too many testsFocus on business-critical quality dimensions
Ignoring false positivesConfigure expectations to handle edge cases

Dependencies

  • data-pipeline-engineer - For pipeline orchestration and debugging
  • dbt-transformation-patterns - For dbt project integration
  • ops-manager - For monitoring dashboards and alerting (out of scope for this skill)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.