Use this skill when implementing data validation, data quality monitoring, data lineage tracking, data contracts, or Great Expectations test suites. Triggers on schema validation, data profiling, freshness checks, row-count anomalies, column drift, expectation suites, contract testing between producers and consumers, lineage graphs, data observability, and any task requiring data integrity enforcement across pipelines.
Instrucciones de origen · Vista previa de solo lectura
name
data-quality
version
0.1.0
description
Use this skill when implementing data validation, data quality monitoring, data lineage tracking, data contracts, or Great Expectations test suites. Triggers on schema validation, data profiling, freshness checks, row-count anomalies, column drift, expectation suites, contract testing between producers and consumers, lineage graphs, data observability, and any task requiring data integrity enforcement across pipelines.
When this skill is activated, always start your first response with the 🧢 emoji.
Data Quality
Data quality is the practice of ensuring that data is accurate, complete, consistent,
timely, and trustworthy as it flows through pipelines and systems. Without explicit
quality gates, bad data propagates silently - corrupting dashboards, training flawed
models, and breaking downstream consumers. This skill covers the five pillars: schema
validation at ingress, expectation-based testing with Great Expectations, data contracts
between producers and consumers, lineage tracking for impact analysis, and continuous
monitoring for anomaly detection.
When to use this skill
Trigger this skill when the user:
Adds data validation or schema enforcement to a pipeline (ingestion, transformation, or serving)
Writes Great Expectations expectation suites or checkpoints
Defines data contracts between a producer team and consumer teams
Implements data lineage tracking or impact analysis
Sets up data quality monitoring dashboards or freshness/volume alerts
Investigates data quality incidents (missing columns, null spikes, schema drift)
Profiles a new dataset to understand distributions and anomalies
Builds row-count, freshness, or distribution-based quality checks
Do NOT trigger this skill for:
General ETL/ELT pipeline orchestration (use an Airflow/dbt skill instead)
Data modeling or warehouse design decisions without a quality focus
Key principles
Validate at boundaries, not in the middle - Enforce quality at ingestion (before
data enters your warehouse) and at serving (before consumers read it). Validating
mid-pipeline catches problems too late to prevent downstream damage and too early to
catch transformation bugs.
Contracts are APIs for data - A data contract is a formal agreement between a
producer and consumer on schema, semantics, SLAs, and ownership. Treat it like a
versioned API - breaking changes require migration paths, not surprise emails.
Test data like you test code - Every table should have expectations that run on
every pipeline execution. Column nullability, uniqueness constraints, value ranges,
referential integrity, and freshness are not optional - they are the unit tests of
data engineering.
Lineage enables impact analysis - You cannot assess the blast radius of a schema
change without knowing what reads from what. Instrument lineage at the query level
(not just table level) so you can trace column-level dependencies.
- A row count of 1M is fine today but means
nothing without historical context. Use statistical anomaly detection (z-score,
moving averages) to catch gradual drift that static thresholds miss.
Monitor trends, not just thresholds
Core concepts
The five dimensions of data quality
Dimension
Question answered
How to measure
Accuracy
Does the data reflect reality?
Cross-reference with source of truth, spot-check samples
A data contract defines: the schema (column names, types, constraints), semantic meaning
(what "revenue" means - gross or net), SLAs (freshness, volume bounds), and ownership
(who to page when it breaks). Contracts are versioned artifacts stored alongside code -
not wiki pages that rot. The producer owns the contract and is responsible for not
shipping breaking changes without a version bump.
Data lineage
Lineage is a directed acyclic graph (DAG) where nodes are datasets (tables, views, files)
and edges are transformations (SQL queries, Spark jobs, dbt models). Column-level lineage
tracks which output columns derive from which input columns. Tools like OpenLineage,
DataHub, and dbt's built-in lineage provide this automatically when integrated into your
orchestrator.
Great Expectations
Great Expectations (GX) is the standard open-source framework for data testing. The core
abstractions are: Data Source (connection to your data), Expectation Suite (a
collection of assertions about a dataset), Validator (runs expectations against data),
and Checkpoint (an orchestratable unit that validates data and triggers actions on
pass/fail). Expectations are declarative - expect_column_values_to_not_be_null - and
produce rich, human-readable validation results.
Common tasks
Write a Great Expectations suite
Define expectations for a table covering nullability, types, ranges, and uniqueness.
Always start with not-null and uniqueness expectations on primary keys before adding
business-logic expectations.
Run a checkpoint in a pipeline
Wire a Great Expectations checkpoint into your orchestrator so validation runs on every load.
import great_expectations as gx
context = gx.get_context()
# Define a checkpoint that validates the orders suite
checkpoint = context.checkpoints.add(
gx.Checkpoint(
name="orders_checkpoint",
validation_definitions=[
gx.ValidationDefinition(
name="orders_validation",
data=context.data_sources.get("warehouse")
.get_asset("orders")
.get_batch_definition("full_table"),
suite=context.suites.get("orders_quality"),
)
],
actions=[
gx.checkpoint_actions.UpdateDataDocsAction(name="update_docs"),
],
)
)
# Run in Airflow task / dbt post-hook / standalone script
result = checkpoint.run()
ifnot result.success:
failing = [r for r in result.run_results.values() ifnot r.success]
raise RuntimeError(f"Data quality check failed: {len(failing)} validations failed")
Define a data contract
Create a YAML contract between a producer and consumer team.
# contracts/orders-v2.yamlapiVersion:datacontract/v1.0kind:DataContractmetadata:name:ordersversion:2.0.0owner:payments-teamconsumers:-analytics-team-ml-teamschema:type:tabledatabase:warehousetable:public.orderscolumns:-name:order_idtype:stringconstraints: [not_null, unique]
description:UUIDprimarykey-name:customer_idtype:stringconstraints: [not_null]
description:FKtocustomers.customer_id-name:total_amounttype:decimal(10,2)constraints: [not_null, gte_0]
description:GrossordertotalinUSD-name:statustype:stringconstraints: [not_null]
allowed_values: [pending, completed, cancelled, refunded]
-name:created_attype:timestampconstraints: [not_null]
sla:freshness:1h# data must be no older than 1 hourvolume:min_rows_per_day:1000max_rows_per_day:500000availability:99.9%breaking_changes:policy:notify_consumers_7_days_beforechannel:"#data-contracts-changes"
Version bump the contract on any schema change. Additive changes (new nullable columns)
are non-breaking. Removing or renaming columns, changing types, or tightening constraints
are breaking.
Implement freshness and volume monitoring
Build SQL-based checks that run on a schedule and alert when data is stale or volume is anomalous.
-- Freshness check: alert if orders table has no data in the last 2 hoursSELECTCASEWHENMAX(created_at) < NOW() -INTERVAL'2 hours'THEN'STALE'ELSE'FRESH'ENDAS freshness_status,
MAX(created_at) AS last_record_at,
NOW() -MAX(created_at) AS staleness_duration
FROM orders;
-- Volume anomaly check: compare today's count to 7-day rolling averageWITH daily_counts AS (
SELECTDATE(created_at) AS dt,
COUNT(*) AS row_count
FROM orders
WHERE created_at >=CURRENT_DATE-INTERVAL'8 days'GROUPBYDATE(created_at)
),
stats AS (
SELECTAVG(row_count) AS avg_count,
STDDEV(row_count) AS stddev_count
FROM daily_counts
WHERE dt <CURRENT_DATE
)
SELECT
dc.row_count AS today_count,
s.avg_count,
(dc.row_count - s.avg_count) /NULLIF(s.stddev_count, 0) AS z_score
FROM daily_counts dc, stats s
WHERE dc.dt =CURRENT_DATE;
-- Alert if z_score < -2 (significantly fewer rows than normal)
Track data lineage with OpenLineage
Emit lineage events from your pipeline so downstream consumers can trace dependencies.
OpenLineage integrates natively with Airflow, Spark, and dbt. Prefer built-in
integration over manual event emission when available.
Profile a new dataset
Use Great Expectations profiling to understand a dataset before writing expectations.
import great_expectations as gx
context = gx.get_context()
datasource = context.data_sources.get("warehouse")
asset = datasource.get_asset("new_table")
batch = asset.get_batch_definition("full_table").get_batch()
# Run a profiler to auto-generate expectations based on data
profiler_result = context.assistants.onboarding.run(
batch_request=batch.batch_request,
)
# Review generated expectations before promoting to a suitefor expectation in profiler_result.expectation_suite.expectations:
print(f"{expectation.expectation_type}: {expectation.kwargs}")
Profiling is a starting point, not an end state. Always review and tighten
auto-generated expectations based on domain knowledge.
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Validating only in the warehouse
Bad data already propagated to consumers before checks run
Validate at ingestion boundaries before data lands
Static thresholds for volume checks
Row counts change over time; fixed thresholds cause alert fatigue
Use z-score or rolling-average anomaly detection
No ownership on data contracts
Contracts without an owner rot and stop reflecting reality
Every contract must name a producing team and a Slack channel
Testing only column types, not semantics
Type checks pass but "revenue" contains negative values or wrong currency
Simple pipelines grow complex; retrofitting lineage is 10x harder
Instrument lineage from day one via OpenLineage or dbt
Running Great Expectations only in CI
Production data differs from test data; CI-only checks miss production drift
Run checkpoints on every production pipeline execution
Gotchas
Static volume thresholds cause alert fatigue - Setting a fixed threshold like "alert if row count < 900,000" breaks as soon as business seasonality kicks in (weekends, holidays, seasonal products). Static thresholds generate false positive alerts that teams learn to ignore. Use z-score anomaly detection against a rolling 7-14 day baseline instead.
Great Expectations profiler expectations promoted without review - The onboarding profiler auto-generates expectations based on observed data distributions. If the data you profile on already contains quality issues (outliers, null spikes), those bad patterns get baked into the expectation suite as acceptable. Always review and tighten profiler-generated expectations with domain knowledge before promoting to production checkpoints.
Data contracts without enforcement - A YAML data contract in a repository that no pipeline actually reads is documentation, not a contract. Contracts only provide value when a CI check or pipeline gate validates that the producer's output conforms to the contract schema and SLA before it lands in the consumer's dataset.
Lineage at table level misses column-level blast radius - Table-level lineage tells you "Table A feeds Table B," but if you rename a column in Table A, you need column-level lineage to know which specific downstream columns and models break. Instrument column-level lineage from the start via dbt's built-in lineage or OpenLineage column facets.
Running checkpoints only in CI, not production - CI validates a sample of test data. Production data has different volumes, distributions, and edge cases that CI fixtures never capture. A checkpoint that passes in CI and never runs in production provides a false sense of security. Run checkpoints on every production pipeline execution, not just on PRs.
References
For detailed content on specific sub-domains, read the relevant file
from the references/ folder:
references/great-expectations-advanced.md - Advanced GX patterns: custom expectations,
data docs hosting, store backends, and multi-batch validation
references/data-contracts-spec.md - Full data contract specification, versioning
strategies, and enforcement patterns
references/lineage-tools.md - Comparison of lineage tools (OpenLineage, DataHub,
Atlan, dbt lineage) and integration guides
Only load a references file if the current task requires deep detail on that sub-domain.
The skill above covers the most common validation, monitoring, and lineage tasks.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
