[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-765d85b2-333b-4d24-8861-8c77414cc79a":3,"$f-HkhAvRifX5PVYyU1OiyAQ5NnnYMypVoP_xo4TwtKeQ":42},{"id":4,"title":5,"description":6,"categoryId":7,"moduleId":8,"tags":9,"prompt":10,"icon":11,"source":12,"sourceUrl":13,"authorId":14,"authorName":15,"isPublic":16,"stars":17,"runs":18,"createdAt":19,"updatedAt":19,"module":20,"category":27,"packages":33},"765d85b2-333b-4d24-8861-8c77414cc79a","monte-carlo-prevent","在SQL\u002Fdbt编辑前，观察Monte Carlo数据表面（表健康、警报、血缘、影响范围）的上下文。","cat_coding_backend","mod_coding","sickn33,coding","---\nname: monte-carlo-prevent\ndescription: \"Surfaces Monte Carlo data observability context (table health, alerts, lineage, blast radius) before SQL\u002Fdbt edits.\"\ncategory: data\nrisk: safe\nsource: community\nsource_repo: monte-carlo-data\u002Fmc-agent-toolkit\nsource_type: community\ndate_added: \"2026-04-08\"\nauthor: monte-carlo-data\ntags: [data-observability, dbt, schema, monte-carlo, lineage]\ntools: [claude, cursor, codex]\n---\n\n# Monte Carlo Prevent Skill\n\nThis 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.\n\nReference files live next to this skill file. **Use the Read tool** (not MCP resources) to access them:\n\n- Full workflow step-by-step instructions: `references\u002Fworkflows.md` (relative to this file)\n- MCP parameter details: `references\u002Fparameters.md` (relative to this file)\n- Troubleshooting: `references\u002FTROUBLESHOOTING.md` (relative to this file)\n\n## When to activate this skill\n\n**Do not wait to be asked.** Run the appropriate workflow automatically whenever the user:\n\n- References or opens a `.sql` file or dbt model (files in `models\u002F`) → run Workflow 1\n- Mentions a table name, dataset, or dbt model name in passing → run Workflow 1\n\n- Describes a planned change to a model (new column, join update, filter change, refactor) → **STOP — run Workflow 4 before writing any code**\n-\n- Adds a new column, metric, or output expression to an existing\n  model → run Workflow 4 first, then ALWAYS offer Workflow 2\n  regardless of risk tier — do not skip the monitor offer\n- Asks about data quality, freshness, row counts, or anomalies → run Workflow 1\n- Wants to triage or respond to a data quality alert → run Workflow 3\n\nPresent the results as context the engineer needs before proceeding — not as a response to a question.\n\n## When NOT to activate this skill\n\nDo not invoke Monte Carlo tools for:\n\n- Seed files (files in seeds\u002F directory)\n- Analysis files (files in analyses\u002F directory)\n- One-off or ad-hoc SQL scripts not part of a dbt project\n- Configuration files (dbt_project.yml, profiles.yml, packages.yml)\n- Test files unless the user is specifically asking about data quality\n\nIf uncertain whether a file is a dbt model, check for {{ ref() }} or {{ source() }}\nJinja references — if absent, do not activate.\n\n### Macros and snapshots — gate edits, skip auto-context\n\nMacro files (`macros\u002F`) and snapshot files (`snapshots\u002F`) are **not** models, so\ndo not auto-fetch Monte Carlo context (Workflow 1) when they are opened. However,\nmacros are inlined into every model that calls them at compile time — a one-line\nmacro change can silently alter dozens of models. Snapshots control historical\ntracking and are similarly sensitive.\n\n**The pre-edit hook gates these files.** If the hook fires for a macro or snapshot,\nidentify which models are affected and run the change impact assessment (Workflow 4)\nfor those models before proceeding with the edit.\n\n---\n\n## REQUIRED: Change impact assessment before any SQL edit\n\n**Before editing or writing any SQL for a dbt model or pipeline, you MUST run Workflow 4.**\n\nThis applies whenever the user expresses intent to modify a model — including phrases like:\n\n- \"I want to add a column…\"\n- \"Let me add \u002F I'm adding…\"\n- \"I'd like to change \u002F update \u002F rename…\"\n- \"Can you add \u002F modify \u002F refactor…\"\n- \"Let's add…\" \u002F \"Add a `\u003Ccolumn>` column\"\n- Any other description of a planned schema or logic change\n- \"Exclude \u002F filter out \u002F remove [records\u002Fcustomers\u002Frows]…\"\n- \"Adjust \u002F increase \u002F decrease [threshold\u002Fparameter\u002Fvalue]…\"\n- \"Fix \u002F bugfix \u002F patch [issue\u002Fbug]…\"\n- \"Revert \u002F restore \u002F undo [change\u002Fprevious behavior]…\"\n- \"Disable \u002F enable [feature\u002Flogic\u002Fflag]…\"\n- \"Clean up \u002F remove [references\u002Fcolumns\u002Fcode]…\"\n- \"Implement [backend\u002Ffeature] for…\"\n- \"Create [models\u002Fdbt models] for…\" (when modifying existing referenced tables)\n- \"Increase \u002F decrease \u002F change [max_tokens\u002Fthreshold\u002Fdate constant\u002Fnumeric parameter]…\"\n- Any change to a hardcoded value, constant, or configuration parameter within SQL\n- \"Drop \u002F remove \u002F delete [column\u002Ffield\u002Ftable]\"\n- \"Rename [column\u002Ffield] to [new name]\"\n- \"Add [column]\" (short imperative form, e.g. \"add a created_at column\")\n- Any single-verb imperative command targeting a column, table, or model\n  (e.g. \"drop X\", \"rename Y\", \"add Z\", \"remove W\")\n\nParameter changes (threshold values, date constants, numeric limits) appear\nsafe but silently change model output. Treat them the same as logic changes\nfor impact assessment purposes.\n\n**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.\n\n---\n\n## Pre-edit gate — check before modifying any file\n\n**Before calling Edit, Write, or MultiEdit on any `.sql` or dbt model\nfile, you MUST check:**\n\n1. Has the synthesis step been run for THIS SPECIFIC CHANGE in the\n   current prompt?\n2. **If YES** → proceed with the edit\n3. **If NO** → stop immediately, run Workflow 4, present the full\n   report with synthesis connected to this specific change.\n   **If risk is High or Medium:** ask \"Do you want me to proceed\n   with the edit?\" and wait for explicit confirmation.\n   **If risk is Low:** use judgment — proceed if straightforward\n   and no concerns found, otherwise ask before editing.\n\n**Important: \"Workflow 4 already ran this session\" is NOT sufficient\nto proceed.** Each distinct change prompt requires its own synthesis\nstep connecting the MC findings to that specific change.\n\nThe synthesis must reference the specific columns, filters, or logic\nbeing changed in the current prompt — not just general table health.\n\nExample:\n\n- ✅ \"Given 34 downstream models depend on is_paying_workspace,\n  adding 'MC Internal' to the exclusion list will exclude these\n  workspaces from all downstream health scores and exports.\n  Confirm?\"\n- ❌ \"Workflow 4 already ran. Making the edit now.\"\n\nThe only exception: if the user explicitly acknowledges the risk\nand confirms they want to skip (e.g. \"I know the risks, just make\nthe change\") — proceed but note the skipped assessment.\n\n## Available MCP tools\n\nAll tools are available via the `monte-carlo` MCP server.\n\n| Tool                         | Purpose                                                              |\n| ---------------------------- | -------------------------------------------------------------------- |\n| `testConnection`             | Verify auth and connectivity                                         |\n| `search`                     | Find tables\u002Fassets by name                                           |\n| `getTable`                   | Schema, stats, metadata for a table                                  |\n| `getAssetLineage`            | Upstream\u002Fdownstream dependencies (call with mcons array + direction) |\n| `getAlerts`                  | Active incidents and alerts                                          |\n| `getMonitors`                | Monitor configs — filter by table using mcons array                  |\n| `getQueriesForTable`         | Recent query history                                                 |\n| `getQueryData`               | Full SQL for a specific query                                        |\n| `createValidationMonitorMac` | Generate validation monitors-as-code YAML                            |\n| `createMetricMonitorMac`     | Generate metric monitors-as-code YAML                                |\n| `createComparisonMonitorMac` | Generate comparison monitors-as-code YAML                            |\n| `createCustomSqlMonitorMac`  | Generate custom SQL monitors-as-code YAML                            |\n| `getValidationPredicates`    | List available validation rule types                                 |\n| `updateAlert`                | Update alert status\u002Fseverity                                         |\n| `setAlertOwner`              | Assign alert ownership                                               |\n| `createOrUpdateAlertComment` | Add comments to alerts                                               |\n| `getAudiences`               | List notification audiences                                          |\n| `getDomains`                 | List MC domains                                                      |\n| `getUser`                    | Current user info                                                    |\n| `getCurrentTime`             | ISO timestamp for API calls                                          |\n\n## Core workflows\n\nEach workflow has detailed step-by-step instructions in `references\u002Fworkflows.md` (Read tool).\n\n### 1. Table health check\n\n**When:** User opens a dbt model or mentions a table.\n**What:** Surfaces health, lineage, alerts, and risk signals. Auto-escalates to Workflow 4 if change intent is detected and risk signals are present.\n\n### 2. Add a monitor\n\n**When:** New column, filter, or business rule is added to a model.\n**What:** Suggests and generates monitors-as-code YAML using the appropriate `create*MonitorMac` tool. Saves to `monitors\u002F\u003Ctable_name>.yml`.\n\n### 3. Alert triage\n\n**When:** User is investigating an active data quality incident.\n**What:** Lists open alerts, checks table state, traces lineage for root cause, reviews recent queries.\n\n### 4. Change impact assessment — REQUIRED before modifying a model\n\n**When:** Any intent to modify a dbt model's logic, columns, joins, or filters.\n**What:** Surfaces blast radius, downstream dependencies, active incidents, monitor coverage, and query exposure. Produces a risk-tiered report with synthesis connecting findings to specific code recommendations. See `references\u002Fworkflows.md` for the full assessment sequence, report format, and synthesis rules.\n\n### 5. Change validation queries\n\n**When:** Explicit engineer request only (e.g. \"validate this change\", \"ready to commit\").\n**What:** Generates 3-5 targeted SQL queries to verify the change behaved as intended. Uses Workflow 4 context — requires both impact assessment and file edit in session.\n\n---\n\n## Post-synthesis confirmation rules\n\nAlways end the synthesis with one clear, specific recommendation in plain English:\n\"Given the above, I recommend: [specific action]\"\n\n**If the risk is High or Medium:** STOP and wait for confirmation before editing\nany file. You must ask the engineer and receive an explicit \"yes\", \"go ahead\",\n\"proceed\", or similar confirmation before making code changes.\nSay: \"Do you want me to proceed with the edit?\"\nDo NOT say: \"Proceeding with the edit.\" — that skips the engineer's decision.\n\n**If the risk is Low:** Use your judgment based on the synthesis findings. If\nthe change is straightforward and the synthesis found no concerns, you may\nproceed. If anything is surprising or worth flagging, ask before editing.\n\n---\n\n## Session markers\n\nThese markers coordinate between the skill and the plugin's hooks. Output each\non its own line when the condition is met.\n\n### Impact check complete\n\nAfter the engineer confirms (High\u002FMedium) or after presenting the synthesis (Low),\noutput one marker per assessed table. **IMPORTANT: use only the table\u002Fmodel name, not the full MCON:**\n\n\u003C!-- MC_IMPACT_CHECK_COMPLETE: \u003Ctable_name> -->\n\n(Use the model filename without .sql extension — NOT \"acme.analytics.orders\" or \"prod.public.client_hub\")\n\nHow many markers to emit depends on how the assessment was triggered:\n\n**Hook-triggered** (the pre-edit hook blocked an edit and instructed you to run\nthe assessment): Be strict — only emit markers for tables whose lineage **and**\nmonitor coverage were fetched directly via Monte Carlo tools in this session. If\nthe engineer describes changes to multiple tables but only one was formally\nassessed, emit only one marker. The pre-edit hook will gate the other tables and\nprompt for their own Workflow 4 runs.\n\n**Voluntarily invoked** (the engineer proactively asked for an impact assessment):\nBe looser — emit markers for all tables the assessment meaningfully covered, even\nif some were assessed via lineage context rather than direct MC tool calls. The\nengineer is already safety-conscious; don't force redundant assessments for tables\nthey clearly considered.\n\n### Monitor coverage gap\n\nWhen Workflow 4 finds zero custom monitors on a table's affected columns, output:\n\n\u003C!-- MC_MONITOR_GAP: \u003Ctable_name> -->\n\nUse only the table\u002Fmodel name (NOT the full MCON). This allows the plugin's hooks\nto remind the engineer about monitor coverage at commit time. Only output this\nmarker when the gap is specifically about the columns or logic being changed —\nnot for general table-level monitor absence.\n\n## Limitations\n- Use this skill only when the task clearly matches the scope described above.\n- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.\n- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.\n","","imported","https:\u002F\u002Fgithub.com\u002Fsickn33\u002Fantigravity-awesome-skills","user_system_seed","SkillOPIC",true,212,1813,"2026-05-16 13:29:33",{"id":8,"name":21,"slug":22,"icon":23,"description":24,"sort":25,"createdAt":26},"编程开发","coding","mdi-code-braces","代码生成、调试、审查，提升开发效率",2,"2026-05-16 12:53:40",{"id":7,"name":28,"slug":29,"icon":30,"description":31,"moduleId":8,"sort":25,"skillCount":32,"createdAt":26},"后端开发","backend","mdi-server","API、数据库、服务端架构",296,[34],{"id":35,"skillId":4,"version":36,"fileName":37,"fileSize":38,"filePath":39,"fileHash":40,"manifest":41,"createdAt":19},"ef1029fb-74fc-4ead-977a-48bff9f0a620","1.0.0","monte-carlo-prevent.zip",15533,"uploads\u002Fskills\u002F765d85b2-333b-4d24-8861-8c77414cc79a\u002Fmonte-carlo-prevent.zip","cdf8b54bca3743ece3ec47ae9add7c3c44472017519c2bd3577037bf6e49a75e","[{\"path\":\"SKILL.md\",\"isDirectory\":false,\"size\":13113},{\"path\":\"references\u002FTROUBLESHOOTING.md\",\"isDirectory\":false,\"size\":1553},{\"path\":\"references\u002Fparameters.md\",\"isDirectory\":false,\"size\":918},{\"path\":\"references\u002Fworkflows.md\",\"isDirectory\":false,\"size\":23000}]",{"code":43,"message":44,"data":45},200,"success",{"items":46,"stats":47,"page":50},[],{"averageRating":48,"totalRatings":48,"ratingCounts":49},0,[48,48,48,48,48],{"limit":51,"offset":48,"hasMore":52,"nextOffset":51,"ratedOnly":16},15,false]