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

When to Use

• Use when this upstream workflow matches the user's stated goal.
• Use when the task requires the procedures documented in this skill.

Monte Carlo Context Detection

This skill determines which Monte Carlo skill or workflow best fits the user's current context. It activates reactively for ambiguous or multi-step data-related messages, gathers signals, and routes to the right skill or workflow.

> Monte Carlo tool routing (required): Always call Monte Carlo MCP tools through this plugin's

> upstream bundled server when installed and verified for the intended account; its historical tool names are

> mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__<tool> (e.g.

> mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__get_alerts). Bare tool names used in this skill

> (get_alerts, search, get_table, …) refer to that bundled server. If the session also has a

> separately-configured monte-carlo-mcp server, do not route to it — it may point at a

> different endpoint or credentials.

This catalog tree does not bundle that server, routing CLAUDE.md, hooks, or companion skills. Verify availability and account identity; do not invent tools or silently use a different tenant. Routing does not authorize monitor creation, deployment, or other writes beyond the user's request.

Reference file for signal definitions: references/signal-definitions.md (relative to this file). Read it before routing.

When to activate this skill

This skill is activated by the CLAUDE.md routing table when:

• The user's message relates to data quality, alerts, incidents, coverage, or Monte Carlo — but doesn't clearly match a single skill in the routing table
• The user's intent is ambiguous or could span multiple skills
• The user asks a broad question like "help me with my data" or "what's going on?"

When NOT to activate this skill

• A skill or workflow is already active in the conversation — the active skill owns the conversation, do not intercept
• The user's message clearly matches a single skill in the CLAUDE.md routing table — route directly, no need for context detection
• The user is editing a dbt model — defer to the prevent skill only when its hooks are verified active
• The user's message is not data-related at all

---

Workflow: Reactive Routing

This skill is purely reactive — it activates for ambiguous or multi-step data-related messages and routes them.

Follow these steps in order.

Step 0: Fast-path clear intent (stop early if matched)

Before doing anything else, check whether the user's message unambiguously matches a single existing skill. If so, skip the rest of this workflow and immediately load that skill — do NOT read references/signal-definitions.md, do NOT make API probes.

| Clear user intent | Skill to load immediately |

|---|---|

| "Check health of [named table]" / "status of [named table]" | ../asset-health/SKILL.md |

| "Create a [monitor type] on [named table]" | ../monitoring-advisor/SKILL.md |

| "Investigate alert on [named table]" / "why is [named table] stale/broken?" | ../incident-response/SKILL.md |

| "What should I monitor?" / "where are my coverage gaps?" | ../proactive-monitoring/SKILL.md |

| "Instrument my agent" / "set up Monte Carlo tracing on [named framework] agent" / "setting up an agent" | ../instrument-agent/SKILL.md |

Context-detection is for ambiguous requests only. If the request is clear, routing through this skill wastes turns and tokens.

If no clear match, proceed to Step 1.

Step 1: Categorize intent

Read references/signal-definitions.md for the full signal catalog. Determine which category the user's message falls into:

| Category | Signals | Example messages |

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

| Specific asset | User mentions a table name, or has a .sql model file open in their IDE | "what's wrong with stg_payments?", "check this table" |

| Active incident | Keywords: alert, broken, stale, failing, incident, triage, wrong data | "I have alerts firing", "data looks wrong", "something broke" |

| Coverage/monitoring | Keywords: monitor, coverage, gaps, unmonitored, what should I watch | "what should I monitor?", "where are my gaps?" |

| Agent instrumentation | Keywords: instrument, set up tracing, set up Monte Carlo tracing, setting up an agent. Often mentions an AI framework (LangChain, LangGraph, OpenAI, Anthropic, CrewAI, Bedrock, SageMaker, Vertex AI) | "instrument my agent", "set up MC tracing on my LangGraph agent", "setting up an agent" |

| General/exploratory | No clear category, broad question | "help me with data quality", "what can Monte Carlo do?" |

Step 2: Gather scope (only if needed)

• Specific asset known (from file context or user mention) → proceed to Step 3
• Active incident, no scope → ask: "Want me to check recent alerts? Any specific time range or severity?"
• Coverage/monitoring, no scope → ask: "Which warehouse should I look at, or should I check across all?"
• General/exploratory → present the categories: "I can help with: (1) investigating active alerts or data issues, (2) analyzing monitoring coverage and creating monitors, or (3) checking the health of specific tables. What are you looking for?"

Step 3: Scoped API probe (when scope is available)

Only make API calls when you have enough context to scope them:

• Specific asset → call get_alerts with the table's MCON or name filter, and get_monitors for that table
• Active incident with scope → call get_alerts with the user's time range / severity filters
• Coverage/monitoring → skip API probe, route directly to proactive monitoring workflow (it handles its own API calls)
• If MCP tool calls fail → report the actual failure and missing evidence; use conversation intent only for routing, never infer healthy assets or configured authentication.

Always scope MCP calls tightly. Unscoped get_alerts, search, or get_monitors on large accounts can return hundreds of results, overflow the tool-result token limit, spill to disk, and force expensive chunk reads — burning user tokens and risking workflow failure. Minimum scoping:

• get_alerts → time filter (created_after, default last 7 days) + at least one of warehouse, table_names, severity
• search → needed to resolve a table name to its MCON (get_table requires MCON). ALWAYS pass limit (e.g. 5), the table name as query, and filter by warehouse_uuid or database/schema. warehouse_types alone ("snowflake") matches thousands of tables. Disambiguation rules when multiple matches return:

1. If the user named a warehouse (e.g. "analytics-snowflake") → auto-pick the match whose warehouse_display_name matches and proceed. Do NOT stop to ask.

2. If the user named a database/schema → auto-pick the match in that database/schema.

3. If multiple matches remain, ask the user to choose the fully qualified asset. is_key_asset is importance metadata, not identity; warehouse or schema matches must also be unique.

• get_monitors → always filter by mcons (table MCON) or warehouse_uuid

If you don't have enough scope, ask the user before calling.

Step 4: Route

Based on the combined signals from Steps 1-3:

| Combined signals | Confidence | Action |

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

| Active alerts found + incident intent | High | Auto-activate incident response workflow: read and follow ../incident-response/SKILL.md |

| Coverage intent + data project detected | High | Auto-activate proactive monitoring workflow: read and follow ../proactive-monitoring/SKILL.md |

| User asks to create a specific monitor (type + table known) | High | Auto-activate monitoring-advisor: read and follow ../monitoring-advisor/SKILL.md |

| Table mentioned + "health" / "status" / "check" intent | High | Auto-activate asset-health: read and follow ../asset-health/SKILL.md |

| Agent instrumentation intent (instrument / set up tracing / setting up an agent) + Python codebase context | High | Auto-activate instrument-agent: read and follow ../instrument-agent/SKILL.md |

| Ambiguous or conflicting signals | Low | Suggest options and wait for user to choose |

High confidence = auto-activate. Load the target skill's SKILL.md and begin executing it immediately. Do not ask for confirmation.

Low confidence = suggest. Present 2-3 options with brief descriptions and let the user choose. Example:

> "Based on what you've described, I can:

> 1. Investigate alerts — triage and fix active data issues (incident response workflow)

> 2. Improve monitoring — find coverage gaps and create monitors (proactive monitoring workflow)

>

> Which would be most helpful?"

Prevent guardrail

If the user is actively editing a dbt model file (making code changes, not just viewing or asking about it) and the prevent skill's hooks are active, do NOT route to any other skill. Instead respond:

>

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