data-quality-checks
GitHub为数据表或管道设计质量检查方案，覆盖完整性、有效性等六大维度。明确每条规则、严重程度及执行工具（如dbt/GE），确保在数据进入看板前拦截异常，防止坏数据污染下游。
Trigger Scenarios
Install
npx skills add mohitagw15856/pm-claude-skills --skill data-quality-checks -g -y
SKILL.md
Frontmatter
{
"name": "data-quality-checks",
"homepage": "https:\/\/mohitagw15856.github.io\/pm-claude-skills\/skill\/data-quality-checks.html",
"metadata": {
"openclaw": {
"emoji": "🛠"
}
},
"description": "Design the data quality checks for a table or pipeline across the standard dimensions. Use when asked to add data quality tests, define DQ checks, catch bad data before it hits dashboards, or set up monitoring for a dataset. Produces a checks plan across completeness, validity, uniqueness, freshness, consistency, and accuracy — each with the rule, severity, and where it runs (dbt test \/ Great Expectations \/ SQL assertion)."
}
Data Quality Checks Skill
Bad data quietly poisons dashboards and models until someone notices the number is wrong. The fix is checks that fail loudly before that — across the standard DQ dimensions. This skill designs them for a specific table/pipeline: the exact rule per dimension, its severity (block vs. warn), and where it runs (dbt test, Great Expectations, or a SQL assertion), so quality is enforced, not hoped for.
Required Inputs
Ask for these only if they aren't already provided:
- The table/pipeline and what it represents (grain, key columns).
- The columns that matter — keys, required fields, enums, ranges, dates.
- Freshness expectation — how current the data must be.
- Tooling — dbt tests, Great Expectations, Soda, or raw SQL assertions.
Output Format
Data Quality Checks: [table]
Checks organised by dimension — each with the rule, severity (🔴 block the pipeline / 🟡 warn), and where it runs:
| Dimension | Check | Rule | Severity | Implement as |
|---|---|---|---|---|
| Completeness | required fields non-null | not_null on [cols] |
🔴 | dbt test |
| Uniqueness | grain key unique | unique on [key] |
🔴 | dbt test |
| Validity | values in allowed set/range | accepted_values / range |
🟡 | GE / SQL |
| Freshness | data is current | max(loaded_at) within SLA | 🔴 | dbt source freshness |
| Consistency | cross-field / cross-table | e.g. totals reconcile, FK exists | 🟡 | SQL assertion |
| Accuracy | matches a source of truth | reconcile vs. system-of-record | 🟡 | SQL assertion |
Notes:
- Severity discipline — only block on checks that should stop the pipeline (a duplicated grain key, stale critical data). Over-blocking trains people to ignore alerts.
- Where to check — at ingestion (catch early) vs. in the model vs. post-build; recommend per check.
- On failure — what happens (halt, quarantine rows, alert + continue) and who's paged.
Quality Checks
- Covers the core dimensions (completeness, uniqueness, validity, freshness, consistency)
- Each check has an explicit rule and a severity (block vs. warn)
- Severity is disciplined — only truly critical checks block the pipeline
- Freshness has a measurable SLA, not "should be recent"
- Each check names where it runs and what happens on failure
Anti-Patterns
- Do not block the pipeline on every check — alert fatigue makes people ignore the real failures; reserve 🔴 for critical
- Do not only test the happy path — the grain key, nulls, and freshness are where the real breakage hides
- Do not write checks with no failure action — a test that fails into the void changes nothing
- Do not skip freshness — stale data that looks fine is the most dangerous kind
- Do not check only one table in isolation — cross-table consistency (FKs, reconciliations) catches integration bugs
Based On
Data-quality practice — the six DQ dimensions, dbt tests / Great Expectations / source-freshness, severity-tiered enforcement.
Version History
- 54fad50 Current 2026-07-19 12:15
