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 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.

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:

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:

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

Examples

User: Apply this skill to my current task.
Assistant: Follow the workflow in this skill, cite limitations, and ask before risky steps.

Limitations

• Imported upstream skill; verify credentials, permissions, and safety boundaries before execution.
• Does not replace environment-specific validation, testing, or maintainer review.