Mohit Aggarwal Data Quality Audit Skill
Bad analysis usually starts with bad data nobody checked. This skill audits a dataset across the dimensions that matter, names the specific issues (and the exact check to confirm each), and prioritises fixes by how much they distort the answer.
Working from a brief
Given a dataset description, sample rows, or a schema, produce the full audit anyway — infer the likely issues for that kind of data and give the concrete check (SQL/pandas-style) to verify each. If given actual data, ground the findings in it. Never just say "check for errors"; specify them.
Required Inputs
Ask for (if not already provided):
- The dataset — schema, a sample, or a description (what each column is, the grain)
- What it'll be used for (the analysis/decision it feeds — focuses the audit)
- Source & freshness (where it comes from, how often it updates)
- Known issues the user already suspects
Output Format
1. Summary
Overall read (🟢 usable / 🟡 fix-first / 🔴 don't trust yet) and the one issue most likely to mislead.
2. Quality scorecard
| Dimension | Check | Finding | Severity |
|---|---|---|---|
| Completeness | nulls / missing per key column | ||
| Uniqueness | duplicate rows / keys | ||
| Validity | type, format, range, allowed values | ||
| Consistency | cross-field & cross-table agreement | ||
| Accuracy | sanity vs known totals / reality | ||
| Timeliness | freshness, gaps in the time series |
3. Specific issues
For each real issue: what it is, the check to confirm it (a concrete query/snippet), why it matters for the intended use, and severity.
4. Fix plan (prioritised)
Ordered by impact-on-the-decision: what to fix first, how (drop / impute / dedupe / cast / clamp / re-source), and what to flag rather than fix.
5. Guardrails
2–3 automated checks to add so these issues get caught next time (e.g. a not-null assertion, a row-count delta alarm, an allowed-values test).
Quality Checks
- Covers all six dimensions, not just missing values
- Each issue comes with a concrete check to confirm it, not just a label
- Severity is judged against the intended use of the data
- Fix plan is prioritised by impact and says fix-vs-flag
- Recommends guardrails to prevent recurrence
Anti-Patterns
- Only checking for nulls and calling it done
- "Clean your data" with no specific issues or checks
- Treating all issues as equally severe regardless of the decision
- Fixing data silently with no record of what was changed