[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FCKEXM4GCW71KBZ6CM2YH5":3,"skill-same:01M6FCKEXM4GCW71KBZ6CM2YH5":109},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":31,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6FCKEXM4GCW71KBZ6CM2YH5","tune-monitor",null,"Analyze a Monte Carlo monitor and recommend config changes to reduce alert noise. Supports metric, custom SQL, validation, and table monitors. Fetches the report, identifies patterns, and suggests tuning.","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],"monitor","tune monitor","tune","main","2026","metric","recommend","reduce","tree","mc","critical","monte-carlo","patterns","wed","github","community","alert","table","analyze","tuning","data","https","license","toolkit","sql","config","2026-11-10 10:12:30",false,"---\nname: tune-monitor\ndescription: Analyze a Monte Carlo monitor and recommend config changes to reduce alert noise. Supports metric, custom SQL, validation, and table monitors. Fetches the report, identifies patterns, and suggests tuning.\nrisk: critical\nsource: https:\u002F\u002Fgithub.com\u002Fmonte-carlo-data\u002Fmc-agent-toolkit\u002Ftree\u002Fmain\u002Fskills\u002Ftune-monitor\nsource_repo: monte-carlo-data\u002Fmc-agent-toolkit\nsource_type: community\ndate_added: 2026-07-01\nlicense: Apache-2.0\nlicense_source: https:\u002F\u002Fgithub.com\u002Fmonte-carlo-data\u002Fmc-agent-toolkit\u002Fblob\u002Fmain\u002FLICENSE\n---\n## Bundled upstream support\n\nSupporting files are included at skill-relative paths. See [UPSTREAM-NOTICE.md](UPSTREAM-NOTICE.md) for their pinned sources, licenses, hashes, and import changes.\n\n# Tune Monitor: Noise Reduction Analysis\n## When to Use\n\nUse this skill when you need analyze a Monte Carlo monitor and recommend config changes to reduce alert noise. Supports metric, custom SQL, validation, and table monitors. Fetches the report, identifies patterns, and suggests tuning.\n\n\nYou are a Monte Carlo monitor tuning agent. Your job is to fetch a monitor's report, dump it to\na file for reference, analyze the alert patterns, and recommend concrete configuration changes to\nreduce noise while explicitly assessing the detection signal that could be lost. Save a report only to an approved private location; redact sensitive SQL, resource identifiers and segment values where necessary.\n\n> **Tool routing:** Discover the actual Monte Carlo connector and inspect its tool schemas. The upstream plugin namespace is an example, not a server bundled in this catalog skill. Verify the intended account\u002Fworkspace and credentials before reads or writes; never silently switch connectors. If unavailable, request the exported report\u002Fconfig and provide offline recommendations without claiming tool execution.\n\n**Arguments:** $ARGUMENTS\n\nReference files live next to this skill file. **Use the Read tool** (not MCP resources) to access\nthem:\n\n- Metric monitor tuning: `references\u002Fmetric-monitor.md` (relative to this file)\n- Custom SQL monitor tuning: `references\u002Fcustom-sql-monitor.md` (relative to this file)\n- Validation monitor tuning: `references\u002Fvalidation-monitor.md` (relative to this file)\n- Table monitor tuning: `references\u002Ftable-monitor.md` (relative to this file)\n\n---\n\n## Prerequisites\n\n- **Required:** Monte Carlo MCP server (`monte-carlo-mcp`) must be configured and authenticated\n\n---\n\n## Available MCP tools\n\n| Tool | Purpose |\n|---|---|\n| `get_monitor_report` | Fetch a monitor's alert history, incident details, and troubleshooting summaries |\n| `get_monitors` | Fetch monitor configuration (type, thresholds, schedule, segments) |\n| `create_or_update_metric_monitor` | Update a metric monitor in place (pass `monitor_uuid`; used in Phase 5) |\n| `create_or_update_sql_monitor` | Update a custom SQL monitor in place (pass `monitor_uuid`; used in Phase 5) |\n| `create_or_update_validation_monitor` | Update a validation monitor in place (pass `monitor_uuid`; used in Phase 5) |\n| `create_or_update_table_monitor_asset_rule` | Tune freshness \u002F volume change \u002F unchanged size for a single table; pick the per-metric variant via `rule_type` (`last_updated_on` \u002F `total_row_count` \u002F `total_row_count_last_changed_on`). One call per `(table, metric)` pair (used in Phase 5). |\n\nAll three `create_or_update_*_monitor` tools follow a **two-call preview-then-confirm pattern**: the first call (with the default `dry_run=True`) returns the rendered MaC YAML for review in `result.yaml`; the second call (`dry_run=False`) deploys the change live and returns a deep link in `result.instructions`. **Always pass `monitor_uuid=\u003Cuuid>`** on both calls so the tool updates the existing monitor in place rather than creating a new one.\n\n---\n\n## Phase 0: Validate Input\n\nExtract the monitor UUID from `$ARGUMENTS`. It must be a valid UUID (format:\n`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`).\n\nIf no UUID is provided or it doesn't look like a UUID, stop and tell the user:\n\n> Please provide a monitor UUID. Example: `\u002Ftune-monitor 94c2dd3a-ef49-40f8-b1c1-741ba057cabf`\n\n---\n\n## Phase 1: Fetch Monitor Report\n\nCall `get_monitor_report` with:\n- `monitor_uuid`: the UUID from `$ARGUMENTS`\n- `max_incidents`: 50 as an initial bounded page; inspect actual date coverage, pagination\u002Ftruncation and total count before claiming 7\u002F30-day totals\n\nDistinguish not-found from authentication\u002Fpermission\u002Fnetwork errors and a valid empty incident history. Report the actual failure or coverage; do not label every empty\u002Ferror response as missing monitor.\n\nAlso fetch the monitor's full config via `get_monitors` with:\n- `monitor_ids`: [`{monitor_uuid}`]\n- `include_fields`: [`config`]\n\nRun both calls in parallel.\n\n---\n\n## Phase 1.5: Determine Monitor Type and Load Reference\n\nFrom the `get_monitors` config response, determine the monitor type:\n\n| Config indicator | Type | Reference file |\n|---|---|---|\n| Monitor type is a metric monitor variant (e.g., metric, field health) | Metric | `references\u002Fmetric-monitor.md` |\n| Monitor type is a custom SQL rule \u002F custom monitor | Custom SQL | `references\u002Fcustom-sql-monitor.md` |\n| Monitor type is a validation rule \u002F validation monitor | Validation | `references\u002Fvalidation-monitor.md` |\n| Monitor type is a table monitor (freshness, volume, schema across tables) | Table | `references\u002Ftable-monitor.md` |\n\n**Read** the appropriate reference file using the Read tool with the path relative to this skill\nfile. The reference contains type-specific config fields to extract, recommendation guidance, and\napply-changes instructions.\n\nIf the monitor type is not metric, custom SQL, validation, or table, stop and tell the user:\n\n> This skill supports tuning metric, custom SQL, validation, and table monitors. This monitor\n> is a {type} monitor, which is not supported.\n\n---\n\n## Phase 2: Analyze the Report\n\nAnalyze the monitor report and config together. Focus on:\n\n### 2a. Alert volume & frequency\n- How many incidents in the last 30 days? Last 7 days?\n- What is the firing cadence — multiple times per day? Daily? Sporadic?\n- Are incidents clustered in time (bursts) or spread evenly?\n\n### 2b. Anomaly patterns\n- Which segments (field values) are firing most? Are they the same segments repeatedly?\n- Are anomalies consistently marginal (just above threshold) or severe?\n- Are any anomalies from sparse\u002Fbursty event types that naturally spike?\n- Are anomalies caused by known operational events (deployments, batch jobs, bulk user actions)?\n- For validation monitors: how many invalid rows per incident? Is the count stable or growing?\n- For table monitors: which (table, metric) pairs are firing most? Are they the same repeatedly?\n\n### 2c. Current configuration\nExtract the current configuration. The specific fields to look for are documented in the per-type\nreference loaded in Phase 1.5. At minimum, extract:\n- Monitor type and what it measures\n- Schedule interval\n- Audiences \u002F notification channels\n- Whether the monitor uses ML thresholds or explicit thresholds\n\n### 2d. Troubleshooting analysis (if available)\nLook at any troubleshooting TL;DRs in the report. Note:\n- Are most anomalies assessed as \"likely normal data variation\"?\n- Are there recurring root causes?\n- Is there a blind spot (e.g., no upstream metadata)?\n\n---\n\n## Phase 3: Generate Recommendations\n\nBased on the analysis, produce a prioritized list of recommendations. For each recommendation:\n- State the **problem** it solves\n- Give the **specific config change** (use exact field names from the MC config schema)\n- Explain the **trade-off** (what signal might be lost)\n\n### General recommendations (all monitor types)\n\n#### Sensitivity tuning (ML thresholds only)\nThis applies to any monitor that uses ML thresholds — both metric monitors and custom SQL monitors.\nSkip this section for validation monitors (they don't use ML thresholds), for table monitors\n(they have their own per-metric sensitivity — see the table monitor reference), and for monitors\nwith explicit thresholds (for custom SQL monitors, see threshold adjustment in the per-type\nreference instead).\n\n- If anomalies are consistently marginal AND independently verified as normal variation against business\u002Fdata-quality requirements (TSA output alone is a hypothesis) → recommend lowering sensitivity one step:\n  - If current sensitivity is `HIGH` → recommend `\"sensitivity\": \"medium\"`\n  - If current sensitivity is `MEDIUM` or `AUTO` → recommend `\"sensitivity\": \"low\"`\n- If current sensitivity is already `LOW` and still noisy → note this isn't a sensitivity issue\n\n#### Schedule \u002F interval\n- If the monitor fires multiple times per day but anomalies always resolve within hours → recommend\n  deduplicating notifications first; increasing the interval (e.g., 720 to 1440 min) can miss short incidents and increases detection delay, so compare against the detection SLA\n- If anomalies are caused by data arriving late → recommend increasing `collection_lag`\n\n#### Snooze \u002F training period\n- If the monitor was recently created (\u003C30 days) and is still learning patterns → recommend\n  waiting for the model to stabilize before tuning\n\n#### Audience \u002F notification routing\n- If routing is noisy, inspect current audiences and accountable owners. Propose severity-based routing or deduplication while preserving escalation for genuine failures; no audiences does not itself explain noise. Do not remove all notifications without explicit ownership and blind-spot acceptance\n\n### Type-specific recommendations\n\nFor type-specific recommendations (WHERE conditions, segment exclusion, aggregation changes,\nthreshold adjustment, SQL modifications, alert condition modifications, per-table-metric\nsensitivity tuning), follow the guidance in the per-type reference loaded in Phase 1.5.\n\n---\n\n## Phase 4: Present the Report\n\nOutput a structured analysis. **This is the primary output — include it in full.**\n\n```markdown\n## Monitor Tune Report: {monitor_uuid}\n\n**Monitor:** {display_name or mac_name}\n**Type:** {monitor type — metric, custom SQL, validation, or table}\n**Table:** {table}\n**What it monitors:** {metric and segments, SQL query summary, validation conditions, or table\u002Fmetric coverage}\n**Current sensitivity:** {sensitivity or \"AUTO (default)\" or \"N\u002FA (explicit thresholds)\"}\n**Schedule:** every {interval_minutes \u002F 60}h\n\n### Alert Summary (last 30 days)\n- Total alerts: {count}\n- Firing frequency: {e.g., \"~twice daily\", \"daily\", \"sporadic\"}\n- Most noisy segments: {top 2-3 segment values by alert count, or N\u002FA for custom SQL\u002Fvalidation}\n- Most noisy (table, metric) pairs: {for table monitors: top pairs by anomaly count}\n\n### Root Cause Pattern\n{1-3 sentence summary of what the alerts represent — operational events, bursty data, model\nmiscalibration, genuine issues, etc.}\n\n### Recommendations\n\n#### 1. {Highest-impact change} [RECOMMENDED]\n**Problem:** ...\n**Change:**\n```yaml\n{specific config field}: {new value}\n```\n**Trade-off:** ...\n\n#### 2. {Second change} [OPTIONAL]\n...\n\n#### 3. {Third change} [OPTIONAL]\n...\n\n### What NOT to change\n{Any configurations that look correct and should be left alone — avoid over-tuning.}\n\n### If these changes are made\n{Report the expected direction and detection-delay\u002Fblind-spot risk. Quantify reduction only from an explicit historical replay or measured trial, including its coverage and limitations.}\n```\n\n**Next step:** \"Want me to apply any of these changes to the monitor config, or explore the alert\nhistory further?\"\n\n---\n\n## Phase 5: Apply Changes (if user requests)\n\nTo apply changes, follow the apply-changes instructions in the per-type reference loaded in\nPhase 1.5. Each reference specifies the correct tool and constraints for that monitor type.\n\nGeneral rules for all types:\n0. **Re-fetch before applying.** Compare the current full config\u002Fversion with the analyzed snapshot; if it changed, recompute the preview. Preserve original config for rollback, and after applying re-read the full config to verify intended changes and unchanged fields. A success link alone is not verification. Define a trial window and rollback trigger based on genuine-incident detection as well as noise.\n1. **Always preview first** — show the user what will change before applying.\n2. **Get explicit confirmation** before applying any change.\n3. **Validate the preview YAML against the schema** — before presenting the preview YAML to the user, fetch the published MaC JSON Schema from `https:\u002F\u002Fclidocs.getmontecarlo.com\u002Fmac\u002Fschema.json` (WebFetch) and check the preview YAML against it. If any field in the YAML does not appear in the schema for the given monitor type, flag it and correct it. Note: the schema validates field names, types, and enum values only — schema constraints vary by version; do not assume validation proves backend compatibility or safe detection. Inspect the installed tool schema too, use a safe YAML loader and retain schema version\u002Fhash. If the schema is unavailable, do not claim validation passed or deploy an unverified field.\n4. **MaC-managed monitors** — if `get_monitors` returns a `mac_name` or the user mentions the monitor is managed via a MaC YAML file, note this before applying: changes made via the API will be overwritten the next time `montecarlo monitors apply` runs. Offer to hand off to `\u002Fmanage-mac` (edit workflow) instead so the YAML file stays the source of truth.\n\n---\n\n## Guidelines\n\n- **Be specific.** Generic advice like \"reduce sensitivity\" is less useful than exact config changes.\n- **Prefer surgical changes.** A targeted WHERE condition beats a blunt sensitivity reduction.\n- **Preserve signal.** Always explain what genuine anomalies would still be caught after tuning.\n- **Cite evidence.** Reference specific incident dates, segment values, and counts from the report.\n- **Degrade gracefully.** If troubleshooting runs are missing, note the limited context and\n  reason from alert patterns alone.\n- **Add `$schema` when saving YAML to a file.** If the user asks to save the MaC YAML to a file, add `# yaml-language-server: $schema=https:\u002F\u002Fclidocs.getmontecarlo.com\u002Fmac\u002Fschema.json` as the first line of that file.\n\n## Limitations\n\n- Use this skill only when the task clearly matches its upstream source and local project context.\n- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.\n- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.\n","## Bundled upstream support\n\nSupporting files are included at skill-relative paths. See [UPSTREAM-NOTICE.md](UPSTREAM-NOTICE.md) for their pinned sources, licenses, hashes, and import changes.\n\n# Tune Monitor: Noise Reduction Analysis\n## When to Use\n\nUse this skill when you need analyze a Monte Carlo monitor and recommend config changes to reduce alert noise. Supports metric, custom SQL, validation, and table monitors. Fetches the report, identifies patterns, and suggests tuning.\n\n\nYou are a Monte Carlo monitor tuning agent. Your job is to fetch a monitor's report, dump it to\na file for reference, analyze the alert patterns, and recommend concrete configuration changes to\nreduce noise while explicitly assessing the detection signal that could be lost. Save a report only to an approved private location; redact sensitive SQL, resource identifiers and segment values where necessary.\n\n> **Tool routing:** Discover the actual Monte Carlo connector and inspect its tool schemas. The upstream plugin namespace is an example, not a server bundled in this catalog skill. Verify the intended account\u002Fworkspace and credentials before reads or writes; never silently switch connectors. If unavailable, request the exported report\u002Fconfig and provide offline recommendations without claiming tool execution.\n\n**Arguments:** $ARGUMENTS\n\nReference files live next to this skill file. **Use the Read tool** (not MCP resources) to access\nthem:\n\n- Metric monitor tuning: `references\u002Fmetric-monitor.md` (relative to this file)\n- Custom SQL monitor tuning: `references\u002Fcustom-sql-monitor.md` (relative to this file)\n- Validation monitor tuning: `references\u002Fvalidation-monitor.md` (relative to this file)\n- Table monitor tuning: `references\u002Ftable-monitor.md` (relative to this file)\n\n---\n\n## Prerequisites\n\n- **Required:** Monte Carlo MCP server (`monte-carlo-mcp`) must be configured and authenticated\n\n---\n\n## Available MCP tools\n\n| Tool | Purpose |\n|---|---|\n| `get_monitor_report` | Fetch a monitor's alert history, incident details, and troubleshooting summaries |\n| `get_monitors` | Fetch monitor configuration (type, thresholds, schedule, segments) |\n| `create_or_update_metric_monitor` | Update a metric monitor in place (pass `monitor_uuid`; used in Phase 5) |\n| `create_or_update_sql_monitor` | Update a custom SQL monitor in place (pass `monitor_uuid`; used in Phase 5) |\n| `create_or_update_validation_monitor` | Update a validation monitor in place (pass `monitor_uuid`; used in Phase 5) |\n| `create_or_update_table_monitor_asset_rule` | Tune freshness \u002F volume change \u002F unchanged size for a single table; pick the per-metric variant via `rule_type` (`last_updated_on` \u002F `total_row_count` \u002F `total_row_count_last_changed_on`). One call per `(table, metric)` pair (used in Phase 5). |\n\nAll three `create_or_update_*_monitor` tools follow a **two-call preview-then-confirm pattern**: the first call (with the default `dry_run=True`) returns the rendered MaC YAML for review in `result.yaml`; the second call (`dry_run=False`) deploys the change live and returns a deep link in `result.instructions`. **Always pass `monitor_uuid=\u003Cuuid>`** on both calls so the tool updates the existing monitor in place rather than creating a new one.\n\n---\n\n## Phase 0: Validate Input\n\nExtract the monitor UUID from `$ARGUMENTS`. It must be a valid UUID (format:\n`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`).\n\nIf no UUID is provided or it doesn't look like a UUID, stop and tell the user:\n\n> Please provide a monitor UUID. Example: `\u002Ftune-monitor 94c2dd3a-ef49-40f8-b1c1-741ba057cabf`\n\n---\n\n## Phase 1: Fetch Monitor Report\n\nCall `get_monitor_report` with:\n- `monitor_uuid`: the UUID from `$ARGUMENTS`\n- `max_incidents`: 50 as an initial bounded page; inspect actual date coverage, pagination\u002Ftruncation and total count before claiming 7\u002F30-day totals\n\nDistinguish not-found from authentication\u002Fpermission\u002Fnetwork errors and a valid empty incident history. Report the actual failure or coverage; do not label every empty\u002Ferror response as missing monitor.\n\nAlso fetch the monitor's full config via `get_monitors` with:\n- `monitor_ids`: [`{monitor_uuid}`]\n- `include_fields`: [`config`]\n\nRun both calls in parallel.\n\n---\n\n## Phase 1.5: Determine Monitor Type and Load Reference\n\nFrom the `get_monitors` config response, determine the monitor type:\n\n| Config indicator | Type | Reference file |\n|---|---|---|\n| Monitor type is a metric monitor variant (e.g., metric, field health) | Metric | `references\u002Fmetric-monitor.md` |\n| Monitor type is a custom SQL rule \u002F custom monitor | Custom SQL | `references\u002Fcustom-sql-monitor.md` |\n| Monitor type is a validation rule \u002F validation monitor | Validation | `references\u002Fvalidation-monitor.md` |\n| Monitor type is a table monitor (freshness, volume, schema across tables) | Table | `references\u002Ftable-monitor.md` |\n\n**Read** the appropriate reference file using the Read tool with the path relative to this skill\nfile. The reference contains type-specific config fields to extract, recommendation guidance, and\napply-changes instructions.\n\nIf the monitor type is not metric, custom SQL, validation, or table, stop and tell the user:\n\n> This skill supports tuning metric, custom SQL, validation, and table monitors. This monitor\n> is a {type} monitor, which is not supported.\n\n---\n\n## Phase 2: Analyze the Report\n\nAnalyze the monitor report and config together. Focus on:\n\n### 2a. Alert volume & frequency\n- How many incidents in the last 30 days? Last 7 days?\n- What is the firing cadence — multiple times per day? Daily? Sporadic?\n- Are incidents clustered in time (bursts) or spread evenly?\n\n### 2b. Anomaly patterns\n- Which segments (field values) are firing most? Are they the same segments repeatedly?\n- Are anomalies consistently marginal (just above threshold) or severe?\n- Are any anomalies from sparse\u002Fbursty event types that naturally spike?\n- Are anomalies caused by known operational events (deployments, batch jobs, bulk user actions)?\n- For validation monitors: how many invalid rows per incident? Is the count stable or growing?\n- For table monitors: which (table, metric) pairs are firing most? Are they the same repeatedly?\n\n### 2c. Current configuration\nExtract the current configuration. The specific fields to look for are documented in the per-type\nreference loaded in Phase 1.5. At minimum, extract:\n- Monitor type and what it measures\n- Schedule interval\n- Audiences \u002F notification channels\n- Whether the monitor uses ML thresholds or explicit thresholds\n\n### 2d. Troubleshooting analysis (if available)\nLook at any troubleshooting TL;DRs in the report. Note:\n- Are most anomalies assessed as \"likely normal data variation\"?\n- Are there recurring root causes?\n- Is there a blind spot (e.g., no upstream metadata)?\n\n---\n\n## Phase 3: Generate Recommendations\n\nBased on the analysis, produce a prioritized list of recommendations. For each recommendation:\n- State the **problem** it solves\n- Give the **specific config change** (use exact field names from the MC config schema)\n- Explain the **trade-off** (what signal might be lost)\n\n### General recommendations (all monitor types)\n\n#### Sensitivity tuning (ML thresholds only)\nThis applies to any monitor that uses ML thresholds — both metric monitors and custom SQL monitors.\nSkip this section for validation monitors (they don't use ML thresholds), for table monitors\n(they have their own per-metric sensitivity — see the table monitor reference), and for monitors\nwith explicit thresholds (for custom SQL monitors, see threshold adjustment in the per-type\nreference instead).\n\n- If anomalies are consistently marginal AND independently verified as normal variation against business\u002Fdata-quality requirements (TSA output alone is a hypothesis) → recommend lowering sensitivity one step:\n  - If current sensitivity is `HIGH` → recommend `\"sensitivity\": \"medium\"`\n  - If current sensitivity is `MEDIUM` or `AUTO` → recommend `\"sensitivity\": \"low\"`\n- If current sensitivity is already `LOW` and still noisy → note this isn't a sensitivity issue\n\n#### Schedule \u002F interval\n- If the monitor fires multiple times per day but anomalies always resolve within hours → recommend\n  deduplicating notifications first; increasing the interval (e.g., 720 to 1440 min) can miss short incidents and increases detection delay, so compare against the detection SLA\n- If anomalies are caused by data arriving late → recommend increasing `collection_lag`\n\n#### Snooze \u002F training period\n- If the monitor was recently created (\u003C30 days) and is still learning patterns → recommend\n  waiting for the model to stabilize before tuning\n\n#### Audience \u002F notification routing\n- If routing is noisy, inspect current audiences and accountable owners. Propose severity-based routing or deduplication while preserving escalation for genuine failures; no audiences does not itself explain noise. Do not remove all notifications without explicit ownership and blind-spot acceptance\n\n### Type-specific recommendations\n\nFor type-specific recommendations (WHERE conditions, segment exclusion, aggregation changes,\nthreshold adjustment, SQL modifications, alert condition modifications, per-table-metric\nsensitivity tuning), follow the guidance in the per-type reference loaded in Phase 1.5.\n\n---\n\n## Phase 4: Present the Report\n\nOutput a structured analysis. **This is the primary output — include it in full.**\n\n```markdown\n## Monitor Tune Report: {monitor_uuid}\n\n**Monitor:** {display_name or mac_name}\n**Type:** {monitor type — metric, custom SQL, validation, or table}\n**Table:** {table}\n**What it monitors:** {metric and segments, SQL query summary, validation conditions, or table\u002Fmetric coverage}\n**Current sensitivity:** {sensitivity or \"AUTO (default)\" or \"N\u002FA (explicit thresholds)\"}\n**Schedule:** every {interval_minutes \u002F 60}h\n\n### Alert Summary (last 30 days)\n- Total alerts: {count}\n- Firing frequency: {e.g., \"~twice daily\", \"daily\", \"sporadic\"}\n- Most noisy segments: {top 2-3 segment values by alert count, or N\u002FA for custom SQL\u002Fvalidation}\n- Most noisy (table, metric) pairs: {for table monitors: top pairs by anomaly count}\n\n### Root Cause Pattern\n{1-3 sentence summary of what the alerts represent — operational events, bursty data, model\nmiscalibration, genuine issues, etc.}\n\n### Recommendations\n\n#### 1. {Highest-impact change} [RECOMMENDED]\n**Problem:** ...\n**Change:**\n```yaml\n{specific config field}: {new value}\n```\n**Trade-off:** ...\n\n#### 2. {Second change} [OPTIONAL]\n...\n\n#### 3. {Third change} [OPTIONAL]\n...\n\n### What NOT to change\n{Any configurations that look correct and should be left alone — avoid over-tuning.}\n\n### If these changes are made\n{Report the expected direction and detection-delay\u002Fblind-spot risk. Quantify reduction only from an explicit historical replay or measured trial, including its coverage and limitations.}\n```\n\n**Next step:** \"Want me to apply any of these changes to the monitor config, or explore the alert\nhistory further?\"\n\n---\n\n## Phase 5: Apply Changes (if user requests)\n\nTo apply changes, follow the apply-changes instructions in the per-type reference loaded in\nPhase 1.5. Each reference specifies the correct tool and constraints for that monitor type.\n\nGeneral rules for all types:\n0. **Re-fetch before applying.** Compare the current full config\u002Fversion with the analyzed snapshot; if it changed, recompute the preview. Preserve original config for rollback, and after applying re-read the full config to verify intended changes and unchanged fields. A success link alone is not verification. Define a trial window and rollback trigger based on genuine-incident detection as well as noise.\n1. **Always preview first** — show the user what will change before applying.\n2. **Get explicit confirmation** before applying any change.\n3. **Validate the preview YAML against the schema** — before presenting the preview YAML to the user, fetch the published MaC JSON Schema from `https:\u002F\u002Fclidocs.getmontecarlo.com\u002Fmac\u002Fschema.json` (WebFetch) and check the preview YAML against it. If any field in the YAML does not appear in the schema for the given monitor type, flag it and correct it. Note: the schema validates field names, types, and enum values only — schema constraints vary by version; do not assume validation proves backend compatibility or safe detection. Inspect the installed tool schema too, use a safe YAML loader and retain schema version\u002Fhash. If the schema is unavailable, do not claim validation passed or deploy an unverified field.\n4. **MaC-managed monitors** — if `get_monitors` returns a `mac_name` or the user mentions the monitor is managed via a MaC YAML file, note this before applying: changes made via the API will be overwritten the next time `montecarlo monitors apply` runs. Offer to hand off to `\u002Fmanage-mac` (edit workflow) instead so the YAML file stays the source of truth.\n\n---\n\n## Guidelines\n\n- **Be specific.** Generic advice like \"reduce sensitivity\" is less useful than exact config changes.\n- **Prefer surgical changes.** A targeted WHERE condition beats a blunt sensitivity reduction.\n- **Preserve signal.** Always explain what genuine anomalies would still be caught after tuning.\n- **Cite evidence.** Reference specific incident dates, segment values, and counts from the report.\n- **Degrade gracefully.** If troubleshooting runs are missing, note the limited context and\n  reason from alert patterns alone.\n- **Add `$schema` when saving YAML to a file.** If the user asks to save the MaC YAML to a file, add `# yaml-language-server: $schema=https:\u002F\u002Fclidocs.getmontecarlo.com\u002Fmac\u002Fschema.json` as the first line of that file.\n\n## Limitations\n\n- Use this skill only when the task clearly matches its upstream source and local project context.\n- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.\n- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.\n",{"name":5,"risk":38,"source":59,"license":14,"date_added":60,"description":7,"source_repo":61,"source_type":43,"license_source":62},"https:\u002F\u002Fgithub.com\u002Fmonte-carlo-data\u002Fmc-agent-toolkit\u002Ftree\u002Fmain\u002Fskills\u002Ftune-monitor",1782864000000,"monte-carlo-data\u002Fmc-agent-toolkit","https:\u002F\u002Fgithub.com\u002Fmonte-carlo-data\u002Fmc-agent-toolkit\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-tune-monitor",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-11 14:20:43",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add boisenoise\u002Fskills-collections --skill tune-monitor",{"tool":75,"command":76},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill tune-monitor",{"tool":78,"command":79},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill tune-monitor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002FSKILL.md",true,[83,89,93,97,101,105],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fcustom-sql-monitor.md","REFERENCE","参考文档",5451,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002Freferences\u002Fcustom-sql-monitor.md",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fmetric-monitor.md",5794,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002Freferences\u002Fmetric-monitor.md",{"path":94,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Ftable-monitor.md",7215,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002Freferences\u002Ftable-monitor.md",{"path":98,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fvalidation-monitor.md",6403,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002Freferences\u002Fvalidation-monitor.md",{"path":102,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":103,"sourceHtmlUrl":104},"UPSTREAM-LICENSE.txt",11357,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002FUPSTREAM-LICENSE.txt",{"path":106,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":107,"sourceHtmlUrl":108},"UPSTREAM-NOTICE.md",1827,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tune-monitor\u002FUPSTREAM-NOTICE.md",[110,136,158,181,199,222],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":114,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":54},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[118,119,120,121,122,123,124,48,125,126,127,128,129,130,131,38,132,133,134,135,32],"web","access","web access","official","development","browser","search","Tools","read","fetch","only","youtube","free tools","platform","free","cover","normal","when",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":140,"sourceHtmlUrl":141,"categories":142,"keywords":144,"publishedAt":54},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[143],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[138,145,146,42,121,122,50,125,147,148,149,150,151,152,153,38,154,155,156,157,32],"MCP","cli","Budget","credentials","team","catalog","use","call","discover","external tools","with","scoped","blob",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":162,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":54},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000038","人力资源",[160,42,121,50,49,169,170,171,172,173,38,174,175,176,155,177,178,179,180,157,138,32],"email","enrichment","business","evidence","phone","ranking","post","job description","for","person","candidate","reason",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":185,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":54},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[189,190,191,42,121,50,192,193,49,194,147,195,46,196,172,38,197,198,157,138,32],"growth","rea","rea growth","produce","content","playbook","marketing","public","observations","company",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":203,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":54},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[207,208,42,209,121,210,50,211,212,213,214,215,38,216,217,218,219,220,221,157],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":226,"sourceHtmlUrl":227,"categories":228,"keywords":229,"publishedAt":54},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[230,231,232,42,121,50,233,234,171,235,236,38,237,238,239,240,241,242,243,157],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]