Agent skill · posthog
authoring-data-quality-checks
Adds and runs data quality checks (dbt-test style assertions) on a project's warehouse tables and saved-query views: not-null, uniqueness, accepted values, referential integrity, row-count bounds, freshness, and custom HogQL. Use when asked to test a model, validate a view, check for nulls or duplicates, add data quality checks, find out why a number looks wrong, or judge whether a warehouse table is trustworthy before using it in an analysis. To describe what data *means* (metrics, certifications, joins), see setting-up-data-catalog instead. Trigger terms: data quality, data test, dbt test, not null check, uniqueness check, freshness check, referential integrity, row count check, validate model, is this table trustworthy.
What it needs
About 4k tokens when loaded.
What this skill does
Authoring data quality checks A check is one assertion about one warehouse table or view. It compiles to a count-only HogQL query and passes when it finds zero failing rows — the same semantics as dbt test. Failing rows are never stored; only counts and the compiled query are, so to see the offending rows you re-run the stored query yourself. rowcount is the exception. It passes when the observed count is within its configured min/max bounds, so its failedrowcount comes back null and its stored query returns that single count, not offending rows. Read the observed count to judge it rather than looking for matched rows. Reads go through SQL (system.informationschema.dataquality); writes and runs go through the data-quality MCP tools. Before you write anything: look Two queries save you from the two most common mistakes — duplicating a check, and checking a column that doesn't exist. Re-creating a byte-identical check is a harmless no-op — checks are keyed by a fingerprint of the subject, type, column, and config, so an identical create upserts. A near-duplicate is not harmless: it doubles the noise for whoever reads the results. If an existing check's assertion is close but wrong, create the corrected check and delete the old one — the assertion (type, column, config) is immutable and the subject is fixed by the URL, so an update that tries to change them is rejected. Update is only for metadata, severity, and ownership. Choosing checks Aim for a handful that would actually catch a real regression, not blanket coverage. A model with twenty checks nobody reads is worse than three that fail meaningfully. Reach for these first, in roughly this order: notnull on the columns downstream joins and filters depend on. The single highest-value check. A null join key silently drops rows. unique on whatever the model claims is its grain. If orders is one row per order, say so. relationships on foreign keys. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills posthog/authoring-data-quality-checks