Generate Monte Carlo Monitors as Code

This skill guides correct creation of Monte Carlo data-observability monitors through MCP tools. Every creation tool runs in dry-run mode and returns monitors-as-code (MaC) YAML - no monitor is ever created directly; the user applies the returned YAML themselves via the Monte Carlo CLI or CI/CD. It covers five monitor types via dedicated MCP tools: createMetricMonitorMac (statistical metrics on fields - null rates, unique counts, row-count change - requiring a timestamp field for aggregation), createValidationMonitorMac (row-level data-quality conditions, alerting on data that matches an INVALID condition), createCustomSqlMonitorMac (arbitrary SQL returning a single number, alerting on thresholds - the most flexible option), createComparisonMonitorMac (comparing metrics between two tables, e.g. dev vs. prod), and createTableMonitorMac (freshness/schema/volume monitoring across a group of tables at database/schema level).

The mandatory procedure has a validation phase that must complete before any creation tool is called: (1) clarify what the user wants monitored and which monitor type fits; (2) identify the exact table and column names via search and getTable - column names must come from getTable, never guessed, since hallucinated column names are the most common cause of monitor-creation failure; (3) check the table's actual domains from getTable and only offer those as domain-assignment choices. Only then does the creation phase proceed: load the relevant reference doc for the monitor type, ask about scheduling (fixed interval, dynamic, or loose - table monitors don't support a schedule field at all), present the full configuration in plain language and get explicit user confirmation before calling the creation tool, then call it and present the returned YAML verbatim wrapped in the standard montecarlo: <type>: [...] MaC structure.

montecarlo:
  metric:
    - <yaml returned by createMetricMonitorMac>

Use it when the user wants to create, add, or set up a monitor, add a freshness check, set up data-quality validation on a table, or generate monitors-as-code YAML. Do not use it for querying/exploring table contents, triaging active alerts, running pre-change impact assessments, checking existing monitor configuration (use getMonitors directly), or editing/deleting existing monitors - those are handled by other workflows. Never skip the user-confirmation step before calling a creation tool, and never reformat or guess at YAML values the tools return.

Input is a monitoring request naming a table, metric, or data-quality rule, resolved through search/getTable into a concrete MCON, column names, and domain assignment. Output is dry-run-generated MaC YAML for the chosen monitor type, wrapped in the standard montecarlo: structure and ready to save to a .yml file and apply via montecarlo monitors apply or CI/CD - never a live-created monitor.

Calls the monte-carlo MCP server's monitor-creation and metadata tools (testConnection, search, getTable, getValidationPredicates, getDomains, and the five create*MonitorMac tools), producing YAML consumed by the Monte Carlo CLI or a dbt/CI pipeline.

Data engineers and analytics engineers setting up Monte Carlo data-observability monitors who want correctly-parameterized monitors-as-code YAML generated from real table metadata rather than guessed configuration.