monte-carlo-prevent – skill Dữ liệu & Khoa học cho agent AI

Monte Carlo Prevent Skill

This skill brings Monte Carlo's data observability context directly into your editor. When you're modifying a dbt model or SQL pipeline, use it to surface table health, lineage, active alerts, and to generate monitors-as-code without leaving Claude Code.

Reference files live next to this skill file. Use the Read tool (not MCP resources) to access them:

• Full workflow step-by-step instructions: references/workflows.md (relative to this file)
• MCP parameter details: references/parameters.md (relative to this file)
• Troubleshooting: references/TROUBLESHOOTING.md (relative to this file)

This is a documentation-only import: no Monte Carlo MCP server, hooks, credentials or runtime are bundled. Discover installed tool schemas and confirm the intended tenant before calls; tool names and parameters below are upstream examples. Local SQL work may proceed with clearly stated impact-assessment limits when MC is unavailable and the user has authorized the edit.

When to activate this skill

Do not wait to be asked. Run the appropriate workflow automatically whenever the user:

• References or opens a .sql file or dbt model (files in models/) → run Workflow 1
• Mentions a table name, dataset, or dbt model name in passing → run Workflow 1

• Describes a planned change to a model (new column, join update, filter change, refactor) → STOP — run Workflow 4 before writing any code

-

• Adds a new column, metric, or output expression to an existing

model → run Workflow 4 first, then ALWAYS offer Workflow 2

regardless of risk tier — do not skip the monitor offer

• Asks about data quality, freshness, row counts, or anomalies → run Workflow 1
• Wants to triage or respond to a data quality alert → run Workflow 3

Present the results as context the engineer needs before proceeding — not as a response to a question.

When NOT to activate this skill

Do not invoke Monte Carlo tools for:

• Seed files (files in seeds/ directory)
• Analysis files (files in analyses/ directory)
• One-off or ad-hoc SQL scripts not part of a dbt project
• Configuration files (dbt_project.yml, profiles.yml, packages.yml)
• Test files unless the user is specifically asking about data quality

Determine whether a file is a dbt model from project paths/configuration; valid models need not contain ref() or source().

Macros and snapshots — gate edits, skip auto-context

Macro files (macros/) and snapshot files (snapshots/) are not models, so

do not auto-fetch Monte Carlo context (Workflow 1) when they are opened. However,

macros are inlined into every model that calls them at compile time — a one-line

macro change can silently alter dozens of models. Snapshots control historical

tracking and are similarly sensitive.

If separately installed and enabled, the upstream pre-edit hook may gate these files. If the hook fires for a macro or snapshot,

identify which models are affected and run the change impact assessment (Workflow 4)

for those models before proceeding with the edit.

---

REQUIRED: Change impact assessment before any SQL edit

Before editing or writing any SQL for a dbt model or pipeline, you MUST run Workflow 4.

This applies whenever the user expresses intent to modify a model — including phrases like:

• "I want to add a column…"
• "Let me add / I'm adding…"
• "I'd like to change / update / rename…"
• "Can you add / modify / refactor…"
• "Let's add…" / "Add a <column> column"
• Any other description of a planned schema or logic change
• "Exclude / filter out / remove [records/customers/rows]…"
• "Adjust / increase / decrease [threshold/parameter/value]…"
• "Fix / bugfix / patch [issue/bug]…"
• "Revert / restore / undo [change/previous behavior]…"
• "Disable / enable [feature/logic/flag]…"
• "Clean up / remove [references/columns/code]…"
• "Implement [backend/feature] for…"
• "Create [models/dbt models] for…" (when modifying existing referenced tables)
• "Increase / decrease / change [max_tokens/threshold/date constant/numeric parameter]…"
• Any change to a hardcoded value, constant, or configuration parameter within SQL
• "Drop / remove / delete [column/field/table]"
• "Rename [column/field] to [new name]"
• "Add [column]" (short imperative form, e.g. "add a created_at column")
• Any single-verb imperative command targeting a column, table, or model

(e.g. "drop X", "rename Y", "add Z", "remove W")

Parameter changes (threshold values, date constants, numeric limits) appear

safe but silently change model output. Treat them the same as logic changes

for impact assessment purposes.

Do not write or edit any SQL until the change impact assessment (Workflow 4) has been presented to the user. The assessment must come first — not after the edit, not in parallel.

---

Pre-edit gate — check before modifying any file

**Before calling Edit, Write, or MultiEdit on any .sql or dbt model

file, you MUST check:**

1. Has the synthesis step been run for THIS SPECIFIC CHANGE in the

current prompt?

2. If YES → proceed with the edit

3. If NO → stop immediately, run Workflow 4, present the full

report with synthesis connected to this specific change.

If risk is High or Medium: ask "Do you want me to proceed

with the edit?" and wait for explicit confirmation.

If risk is Low: use judgment — proceed if straightforward

and no concerns found, otherwise ask before editing.

**Important: "Workflow 4 already ran this session" is NOT sufficient

to proceed.** Each distinct change prompt requires its own synthesis

step connecting the MC findings to that specific change.

The synthesis must reference the specific columns, filters, or logic

being changed in the current prompt — not just general table health.

Example:

• ✅ "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."

The only exception: if the user explicitly acknowledges the risk

and confirms they want to skip (e.g. "I know the risks, just make

the change") — proceed but note the skipped assessment.

Available MCP tools

The upstream workflow expects these tools from a separately configured monte-carlo MCP server; availability must be discovered.

| Tool | Purpose |

| ---------------------------- | -------------------------------------------------------------------- |

| testConnection | Verify auth and connectivity |

| search | Find tables/assets by name |

| getTable | Schema, stats, metadata for a table |

| getAssetLineage | Upstream/downstream dependencies (call with mcons array + direction) |

| getAlerts | Active incidents and alerts |

| getMonitors | Monitor configs — filter by table using mcons array |

| getQueriesForTable | Recent query history |

| getQueryData | Full SQL for a specific query |

| createValidationMonitorMac | Generate validation monitors-as-code YAML |

| createMetricMonitorMac | Generate metric monitors-as-code YAML |

| createComparisonMonitorMac | Generate comparison monitors-as-code YAML |

| createCustomSqlMonitorMac | Generate custom SQL monitors-as-code YAML |

| getValidationPredicates | List available validation rule types |

| updateAlert | Update alert status/severity |

| setAlertOwner | Assign alert ownership |

| createOrUpdateAlertComment | Add comments to alerts |

| getAudiences | List notification audiences |

| getDomains | List MC domains |

| getUser | Current user info |

| getCurrentTime | ISO timestamp for API calls |

Core workflows

Each workflow has detailed step-by-step instructions in references/workflows.md (Read tool).

1. Table health check

When: User opens a dbt model or mentions a table.

What: Surfaces health, lineage, alerts, and risk signals. Auto-escalates to Workflow 4 if change intent is detected and risk sig

… (nội dung đầy đủ có trong gói tải về)