Assess SQL Changes with Data Observability

This skill brings Monte Carlo's data observability context directly into the editor while working on a dbt model or SQL pipeline. It runs automatically, without being asked, in five workflows: (1) table health check, surfacing health, lineage, alerts, and risk signals whenever a .sql file, dbt model, or table name is referenced; (2) add a monitor, generating monitors-as-code YAML into monitors/<table_name>.yml whenever a new column, filter, or business rule is added; (3) alert triage, listing open alerts and tracing lineage for root cause during an active data-quality incident; (4) change impact assessment, which is REQUIRED before any SQL edit to a dbt model - it surfaces blast radius, downstream dependencies, active incidents, and monitor coverage, producing a risk-tiered report before a single line of SQL is written; and (5) change validation queries, generating 3-5 targeted SQL queries on explicit engineer request to confirm a change behaved as intended.

A pre-edit gate blocks calling Edit, Write, or MultiEdit on a .sql or dbt model file until the change-impact synthesis has run for that specific change in the current prompt - a prior run earlier in the session does not count. If the assessed risk is High or Medium, the skill must stop and get an explicit "yes"/"proceed" before editing; for Low risk it may use judgment. Session markers (MC_IMPACT_CHECK_COMPLETE, MC_MONITOR_GAP) coordinate with the surrounding plugin's hooks to signal when an assessment is done or when a changed column has zero monitor coverage.

Use it whenever opening or editing a dbt model, mentioning a table/dataset by name, asking about data quality/freshness/anomalies, or describing any planned change to a model's columns, joins, filters, or hardcoded thresholds - even short imperative phrasing like "add a created_at column" or "drop X" triggers the change-impact assessment first. Do NOT activate it for seed files, analysis files, one-off SQL scripts outside a dbt project, or config files (dbt_project.yml, profiles.yml, packages.yml); if unsure whether a file is a dbt model, check for {{ ref() }} or {{ source() }} Jinja references. Macro and snapshot files are not models and don't get auto-context, but since a macro is inlined into every model that calls it, an edit there still triggers the impact assessment for the affected downstream models via the pre-edit hook.

All data comes from the monte-carlo MCP server: search and getTable for asset lookup and schema/stats, getAssetLineage for upstream/downstream dependencies, getAlerts and getMonitors for active incidents and monitor coverage, getQueriesForTable/getQueryData for query history, and four create*MonitorMac tools that generate validation, metric, comparison, and custom-SQL monitors-as-code YAML. Reference files for full workflow steps, MCP parameter details, and troubleshooting live alongside the skill and must be read with the Read tool, not as MCP resources.

Runs as an editor-embedded companion for Claude, Cursor, and Codex working against dbt/SQL pipelines, coordinating with the surrounding plugin's pre-edit hook via the session markers described above.

Data/analytics engineers editing dbt models or SQL pipelines who need Monte Carlo's table health, lineage, alert, and blast-radius context surfaced automatically before they touch a model, rather than discovering downstream breakage after the change ships.