Assess SQL Changes with Data Observability

The Monte Carlo Prevent skill brings Monte Carlo's data-observability context directly into the editor while working on a dbt model or SQL pipeline, surfacing table health, lineage, active alerts, and monitor coverage without leaving the coding session. It activates automatically (not waiting to be asked) whenever a .sql/dbt model file is opened or a table is mentioned, and runs five workflows: (1) Table health check - health, lineage, alerts, and risk signals when a model is opened or a table mentioned; (2) Add a monitor - suggests and generates monitors-as-code YAML when a new column, filter, or business rule is added; (3) Alert triage - lists open alerts, checks table state, and traces lineage for root cause during an active incident; (4) Change impact assessment - required before any modification to a model's logic, columns, joins, or filters, surfacing blast radius (downstream dependents), active incidents, monitor coverage, and query exposure in a risk-tiered report; (5) Change validation queries - only on explicit engineer request.

The change impact assessment (Workflow 4) is mandatory before writing or editing any SQL for a dbt model - triggered by any expressed intent to add/remove/rename a column, change a filter or threshold, fix a bug, or otherwise modify existing model logic, including short imperative commands ("add a created_at column", "drop X"). Parameter changes like thresholds or date constants are treated the same as logic changes, since they can silently alter model output. A pre-edit gate blocks calling Edit/Write/MultiEdit on any dbt SQL file until this session's synthesis step has connected Monte Carlo's findings to that specific change - a report from an earlier, different change in the same session does not satisfy the gate. For High or Medium risk changes, explicit user confirmation is required before proceeding; the only bypass is the user explicitly acknowledging the risk and asking to skip.

 "Given 34 downstream models depend on is_paying_workspace, adding 'MC Internal'
   to the exclusion list will exclude these workspaces from all downstream health
   scores and exports. Confirm?"
 "Workflow 4 already ran. Making the edit now."

Macro and snapshot files are gated the same way even though they aren't models themselves, since a one-line macro change is inlined into every model that calls it.

Use it automatically whenever a dbt model or SQL pipeline file is being read, discussed, or edited, or when investigating data quality/freshness/anomaly questions or an active alert. Do not activate it for seed files, analysis files, one-off ad hoc SQL scripts outside a dbt project, or dbt configuration files (dbt_project.yml, profiles.yml) - and skip auto-context-fetching (though not the impact-assessment gate) for macros and snapshots specifically since they aren't models.

Input is a dbt model file being opened, discussed, or edited, or a table/dataset name mentioned in conversation. Output is a contextual report: table health and lineage, active alerts, monitor coverage, or - for any proposed change - a risk-tiered blast-radius assessment with specific column/filter-level synthesis, presented as context the engineer needs before proceeding rather than as an answer to an explicit question.

Calls the monte-carlo MCP server's full tool set: search, getTable, getAssetLineage, getAlerts, getMonitors, getQueriesForTable/getQueryData, the create*MonitorMac monitor-generation tools, and alert-management tools (updateAlert, setAlertOwner, createOrUpdateAlertComment).

Data/analytics engineers working in dbt projects who want automatic, proactive visibility into a table's health, lineage, and blast radius before making schema or logic changes, rather than discovering downstream breakage after the fact.