Investigate and remediate data quality incidents

A Monte Carlo skill that investigates and remediates data quality alerts through four sequential workflows. Workflow 1 (Investigation) is mandatory before any fix is proposed: it pulls alert context via get_alerts, assesses triage priority via alert_assessment (incident_likelihood and alert_impact, each HIGH/MEDIUM/LOW), runs root-cause analysis via run_troubleshooting_agent in async mode (since it takes 4-8 minutes and would time out synchronously) while gathering lineage, table context, and query data in parallel, then synthesizes a summary covering what happened, the root cause, TSA's specific verification steps, blast radius, pipeline context, and monitoring gaps - explicitly flagging recurring patterns like repeated incidents in 30 days as chronic rather than one-off. Workflow 2 (Capability Discovery) checks what remediation tools actually exist across three categories - MCP servers (scanning for mcp__*__* patterns), CLI tools (checking via which), and REST APIs - and produces an honest capability list (what it can and can't do), falling back to a documented manual remediation plan with runnable commands when no automated path exists. Workflow 3 (Remediation Execution) maps the TSA root-cause signal to a typical action using an 8-row table (pipeline/DAG failure to restart, dbt model failure to rerun, upstream schema change to assess and update, missing-data volume anomaly to backfill, duplicate-data volume anomaly to dedupe and fix the pipeline, permission/access errors and infrastructure issues to escalate rather than auto-fix, and unknown/complex causes to present findings and ask), always presenting the plan - root cause, proposed action, reasoning, risk, and rollback - to the user before executing, one action at a time, with every action logged via create_or_update_alert_comment. Workflow 4 (Post-remediation) sets the alert status (FIXED, EXPECTED, or NO_ACTION_NEEDED) via update_alert, documents the remediation with a structured comment, and - only as a suggestion, never automatically - proposes a monitor or ticket if the root cause looks systemic rather than one-off.

Use it when someone wants to fix, remediate, or respond to a specific data quality alert or incident, not just triage it. Do NOT use it for triage-only investigation with no remediation intent (the prevent skill's Workflow 3 handles that), creating or configuring monitors (the monitoring-advisor skill), pre-change impact assessments (prevent skill's Workflow 4), or exploring table health without an active issue to fix.

Input is an alert ID, incident, or table name tied to a specific data quality issue. Output is an investigation summary, a presented remediation plan requiring explicit user approval before execution, the executed fix (or a manual runbook if no automated tool is available), and a documented, status-updated alert.

Investigation and post-remediation logging run through Monte Carlo's bundled MCP server (get_alerts, alert_assessment, run_troubleshooting_agent, get_asset_lineage, get_table, get_monitors, get_queries_for_table, update_alert, create_or_update_alert_comment, and others discoverable at runtime). Remediation execution itself uses whatever external MCP servers, CLI tools, or APIs are actually connected - Airflow, dbt, GitHub CLI, and similar - never assuming a fixed toolset.

Data engineers and on-call responders who need to go from a fired data quality alert to a root-caused, safely-executed (or clearly documented manual) fix, with mandatory investigation-before-action and explicit user approval before anything destructive happens.