data-quality-platforms-and-rule-management

Name: data-quality-platforms-and-rule-management
Author: vaquarkhan

19stars4forks

How to install data-quality-platforms-and-rule-management?

vaquarkhan/data-engineering-agent-skills/data-quality-platforms-and-rule-management

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-quality-platforms-and-rule-management

Installs into the current project.

Summary

Guides agents through data-quality operating models and tool selection. Use when designing rule portfolios, severity levels, ownership, evidence, and enforcement across dbt tests, Great Expectations, Deequ, Cuallee, Soda, warehouse-native checks, and platform monitoring workflows

Files · 1

View on GitHub

SKILL.md

1	# Data Quality Platforms And Rule Management
2
3	## Overview
4
5	Use this skill when the question is not only what checks to write, but how the quality program should operate across tools, teams, and publish stages. It helps agents design rule ownership, severity, evidence, and enforcement across multiple quality frameworks.
6
7	## When to Use
8
9	- selecting or combining data-quality tools
10	- designing rule portfolios and severity models
11	- aligning `dbt` tests, `Great Expectations`, `Deequ`, `Cuallee`, `Soda`, or warehouse-native checks
12	- deciding what blocks publish versus what raises warnings
13	- improving long-term maintainability of data-quality controls
14
15	Do not assume more checks automatically improve quality. The operating model matters as much as the framework.
16
17	## Workflow
18
19	1. Define the quality operating model.
20	Clarify:
21	- who owns rules
22	- who triages failures
23	- what blocks publish
24	- what becomes an alert or trend signal
25
26	2. Group rules by purpose.
27	Typical groups:
28	- contract correctness
29	- completeness and freshness
30	- distribution and anomaly checks
31	- reconciliation and financial controls
32	- governance or regulated-data controls
33
34	3. Choose tools intentionally.
35	Decide where each type of rule belongs:
36	- `dbt` tests for warehouse-native model validation
37	- `Great Expectations`, `Deequ`, `Cuallee`, or `Soda` for reusable framework-based checks
38	- warehouse-native monitors for platform-local health signals
39
40	4. Define evidence and routing.
41	Require:
42	- actionable output
43	- severity and ownership
44	- trend visibility
45	- links to incident and publish workflows
46
47	5. Control portfolio growth.
48	Review overlapping, stale, noisy, or low-value checks so quality stays credible and maintainable.
49
50	## Common Rationalizations
51
52	\| Rationalization \| Reality \|
53	\| --- \| --- \|
54	\| "We should standardize on one tool for everything." \| Different rule types often fit different execution surfaces and operating models. \|
55	\| "If a rule fails, we can decide the impact later." \| Publish and incident behavior must already be defined when the rule is introduced. \|
56	\| "More rules always mean better quality." \| Noisy or duplicate checks reduce trust and slow triage. \|
57
58	## Red Flags
59
60	- rule ownership and triage paths are unclear
61	- tools are chosen by preference instead of workload fit
62	- blocking and non-blocking checks are mixed without severity logic
63	- evidence is hard to review or trend over time
64	- stale, overlapping, or low-signal rules accumulate unchecked
65
66	## Verification
67
68	- [ ] The quality operating model defines ownership and severity clearly
69	- [ ] Rule groups map to real delivery risks and publish stages
70	- [ ] Tool choices fit execution surfaces and maintenance needs
71	- [ ] Evidence and routing are reviewable and actionable
72	- [ ] Portfolio sprawl is controlled over time

People who liked this also viewed

6 picks

Type

data-quality-platforms-and-rule-management

19stars4forks

View on GitHub

How to install data-quality-platforms-and-rule-management?

vaquarkhan/data-engineering-agent-skills/data-quality-platforms-and-rule-management

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-quality-platforms-and-rule-management

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Data Quality Platforms And Rule Management
2
3	## Overview
4
5	Use this skill when the question is not only what checks to write, but how the quality program should operate across tools, teams, and publish stages. It helps agents design rule ownership, severity, evidence, and enforcement across multiple quality frameworks.
6
7	## When to Use
8
9	- selecting or combining data-quality tools
10	- designing rule portfolios and severity models
11	- aligning `dbt` tests, `Great Expectations`, `Deequ`, `Cuallee`, `Soda`, or warehouse-native checks
12	- deciding what blocks publish versus what raises warnings
13	- improving long-term maintainability of data-quality controls
14
15	Do not assume more checks automatically improve quality. The operating model matters as much as the framework.
16
17	## Workflow
18
19	1. Define the quality operating model.
20	Clarify:
21	- who owns rules
22	- who triages failures
23	- what blocks publish
24	- what becomes an alert or trend signal
25
26	2. Group rules by purpose.
27	Typical groups:
28	- contract correctness
29	- completeness and freshness
30	- distribution and anomaly checks
31	- reconciliation and financial controls
32	- governance or regulated-data controls
33
34	3. Choose tools intentionally.
35	Decide where each type of rule belongs:
36	- `dbt` tests for warehouse-native model validation
37	- `Great Expectations`, `Deequ`, `Cuallee`, or `Soda` for reusable framework-based checks
38	- warehouse-native monitors for platform-local health signals
39
40	4. Define evidence and routing.
41	Require:
42	- actionable output
43	- severity and ownership
44	- trend visibility
45	- links to incident and publish workflows
46
47	5. Control portfolio growth.
48	Review overlapping, stale, noisy, or low-value checks so quality stays credible and maintainable.
49
50	## Common Rationalizations
51
52	\| Rationalization \| Reality \|
53	\| --- \| --- \|
54	\| "We should standardize on one tool for everything." \| Different rule types often fit different execution surfaces and operating models. \|
55	\| "If a rule fails, we can decide the impact later." \| Publish and incident behavior must already be defined when the rule is introduced. \|
56	\| "More rules always mean better quality." \| Noisy or duplicate checks reduce trust and slow triage. \|
57
58	## Red Flags
59
60	- rule ownership and triage paths are unclear
61	- tools are chosen by preference instead of workload fit
62	- blocking and non-blocking checks are mixed without severity logic
63	- evidence is hard to review or trend over time
64	- stale, overlapping, or low-signal rules accumulate unchecked
65
66	## Verification
67
68	- [ ] The quality operating model defines ownership and severity clearly
69	- [ ] Rule groups map to real delivery risks and publish stages
70	- [ ] Tool choices fit execution surfaces and maintenance needs
71	- [ ] Evidence and routing are reviewable and actionable
72	- [ ] Portfolio sprawl is controlled over time

People who liked this also viewed

6 picks

Type