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 bundled server, whose fully-qualified 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.

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 which auto-activates via hooks
• 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 (auth not configured) → skip API, fall back to conversation intent alone

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 one match is flagged is_key_asset: true and others aren't → auto-pick the key asset.
  4. Only ask the user to disambiguate when none of the above resolve it.
• 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:

"The prevent skill will automatically handle impact assessment for dbt model changes via its pre-edit hooks. No additional routing needed."