This skill should be used when the user asks "how-to" or factual questions about Nightingale (n9e) — UI/where-to-click, business groups/subscription rules/mute rules/edge mode, Token usage, notification pipeline, self-healing trigger conditions; OR about categraf input plugin field meanings, metric names, defaults, environment variables, config syntax (e.g. "how to write [[instances]]", "unit of ping_average_response_ms"). NOT for actively troubleshooting an alert or querying metrics.
Answers "how do I deploy the categraf collector". Trigger scenarios: the user asks "how to install categraf / how to deploy categraf / run categraf with Docker / install categraf on Windows / how to register categraf as a system service / report categraf to Nightingale / how to write categraf config.toml / how to verify that categraf is collecting data". Covers binary + systemd, Docker, Windows, K8s tips, key configuration, and common verification commands. This skill is instructional/guidance-oriented, calls no tools, and outputs ready-to-paste commands and configuration snippets.
Create/edit Nightingale AI Skills. Use when the user wants to create a new skill, codify a troubleshooting or operations workflow into a reusable skill, build a skill that can run scripts (Python/Bash), or modify/improve/optimize an existing self-built skill. Use this skill whenever the user says things like "make a skill", "save this workflow as a skill", "teach the AI a new trick", "tweak that skill of mine", "let the AI learn to troubleshoot following these steps", etc.
One-stop assistant for creating, editing, and troubleshooting Nightingale (n9e) alert mute rules (alert_mute). Use it when the user asks to "create a mute rule / mute an alert / silence an alert / do-not-disturb during a maintenance window / set up periodic muting / mute every early morning / adjust or extend a mute / troubleshoot why a mute isn't working". Muting takes effect during the event evaluation stage (muted events are neither persisted nor notified); to configure "which events get notified to whom", use notification rules (→ notify-rule-copilot); to investigate "why didn't I get a notification", go to alert troubleshooting (→ alert-rule-troubleshoot).
This skill should be used when the user reports that an alert rule is "not firing", "no alert was sent", "the rule didn't trigger", "the rule isn't working", "it should have alerted but didn't", "why didn't I get an alert", "alert rule not firing", or wants to diagnose why a specific alert rule failed to produce an event/notification. Use this skill to troubleshoot "why an alert rule did not fire as expected", as opposed to taking an existing alert and finding its root cause (for the latter, use ops-troubleshooting). Only supported on Release 22 and above.
One-stop assistant for creating, editing, and troubleshooting Nightingale (n9e) alert subscription rules (alert_subscribe). Use when the user asks to "create a subscription rule / subscribe to alerts / forward alert events / CC another team / escalate alerts (notify someone else after N minutes unhandled) / receive alerts across business groups / troubleshoot a subscription not taking effect". A subscription is a "copy + secondary routing" of events at the notification stage; to configure "who an event directly notifies" use notification rules (→ notify-rule-copilot), and to stop receiving alerts use muting (→ alert-mute-copilot).
Analyze the data health of a given dashboard on Nightingale (n9e) over a time window. Use when the user asks to "analyze what problems a dashboard has", "check whether the xx dashboard has been normal over the last 24 hours", "inspect this dashboard", or "does this dashboard have any anomalies". Distinct from modifying a dashboard (modify-dashboard) and creating a dashboard (create-dashboard).
**Create alert rules**. Prefer reusing the validated rules in integrations (standard components like Linux/MySQL/Redis/Kafka/PostgreSQL/Elasticsearch all ship ready-made rule packs); import as many rules as the user needs—one rule, a batch, or a whole pack. Only hand-write a custom rule when integrations has nothing that fits. Supports all data sources: Prometheus / Loki / ES / OpenSearch / MySQL / PG / TDengine / ClickHouse / Doris / VictoriaLogs / Host. ⚠️ **Do NOT use this skill for bulk YAML imports**—when the user provides a URL or a YAML file, awesome-prometheus-alerts, node-exporter.yml, and the like, use import-prom-rule instead. Triggers: create an alert / add an alert / help me set up a CPU alert / add a set of alert rules for MySQL / configure common alerts for a host / I want to monitor a metric.