Nightingale is an open-source monitoring and alerting system that connects to stored metrics and log data, evaluates alert rules, and distributes notifications. Operations teams use it to manage alarms and explore observability data alongside existing data sources and collectors. Catalogue add-ons provide skills for operating Nightingale.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ccfos/nightingale --skill modify-task-tplgit clone --depth 1 https://github.com/ccfos/nightingaleWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ccfos/nightingale/modify-task-tpl)<a href="https://agentmods.dev/skills/ccfos/nightingale/modify-task-tpl"><img src="https://agentmods.dev/badge/skills/ccfos/nightingale/modify-task-tpl/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ccfos/nightingale/modify-task-tpl"><img src="https://agentmods.dev/badge/skills/ccfos/nightingale/modify-task-tpl.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 12 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 256 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 256 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 256 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 256 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 256 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 256 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 260 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Supply Chain · line 261 Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.Fix: Avoid downloading and executing remote scripts. Use trusted packages from PyPI/npm. If remote fetch is required, verify checksums and use HTTPS.
- high Supply Chain · line 261 Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.Fix: Avoid downloading and executing remote scripts. Use trusted packages from PyPI/npm. If remote fetch is required, verify checksums and use HTTPS.
- high Privilege Escalation · line 603 Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.Fix: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
- medium Excessive Agency · line 237 Skill allows unbounded resource consumption (API calls, storage, compute). Without rate limits or quotas, a compromised or misbehaving agent can cause denial-of-service or cost overruns.Fix: Set explicit rate limits, timeouts, and resource quotas for API calls, file operations, and compute. Implement circuit breakers for runaway loops.
- medium Excessive Agency · line 237 Skill allows unbounded resource consumption (API calls, storage, compute). Without rate limits or quotas, a compromised or misbehaving agent can cause denial-of-service or cost overruns.Fix: Set explicit rate limits, timeouts, and resource quotas for API calls, file operations, and compute. Implement circuit breakers for runaway loops.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00168 | $0.07747 |
| Opus 5.5 | $0.00067 | $0.03099 |
| Sonnet 5.5 | $0.00034 | $0.01549 |
| Haiku 4.5 | $0.00017 | $0.00775 |
Grade A, and why
modify-task-tpl scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 733 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Nightingale (n9e) Alert Self-Healing Script (task_tpl) Generation
Nightingale alert self-healing is the ibex subsystem: when an alert rule's callbacks field is written as ${ibex}/<task_tpl_id>, after an alert event fires it pulls up the script of the corresponding task_tpl on the machine matching the current event's TargetIdent and runs it on that machine's categraf. The script receives the labels of the current alert through stdin.
This skill focuses on writing/modifying the task_tpl.script field itself—it does not cover creating alert rules, configuring recipients, or editing notification templates.
1. Scope: First Determine Which Layer the User Is Changing
The Nightingale alert pipeline has four layers, and each goes through a different skill:
| Layer | Entity | Key files | Handled by this skill |
|---|---|---|---|
| Self-healing script task_tpl | task_tpl table |
models/task_tpl.go, alert/sender/ibex.go |
Yes |
| Alert rule | alert_rule table |
models/alert_rule.go |
No (use create-alert-rule) |
| Notification template | notify_tpl table |
models/notify_tpl.go |
No (use generate-message-template) |
| Notification channel | notify_channel table |
models/notify_channel.go |
No (use notify-channel-copilot) |
Judgment criteria: the user's wording contains "script/shell/bash/python/jq/parse/execute/timeout"—this skill; contains "PromQL/threshold/trigger condition"—alert rule; contains "template/body/field rendering"—message template; contains "URL/Webhook/signature"—notification channel.
2. Data Model (What the User Can Fill In, Which Fields Nightingale Actually Uses)
TaskTpl (models/task_tpl.go:17-35)
| Field | Type | Meaning |
|---|---|---|
id |
int64 | Primary key; this is what ${ibex}/<id> in the alert rule callbacks references |
group_id |
int64 | Business group (permission boundary, validated by CanDoIbex) |
title |
string | Template name; at execution time it is concatenated into <title> FH: <hostname> and written as the task title |
script |
string | The main field this skill operates on |
args |
string | Command-line arguments. If the caller does not pass args when the alert fires and executes, the default value here is used |
tags |
string | Space-separated tags, used for template list filtering/classification, does not affect execution |
account |
string | Which user identity to run as on the target machine (e.g. root) |
batch |
int | Number of hosts running concurrently per batch. Self-healing usually only runs on the host that triggered it, so 0 is fine |
tolerance |
int | Allowed failure count within a batch. Leave at 0 for single-host self-healing scenarios |
timeout |
int | Seconds. 0 → defaults to 30; > 5 days → rejected |
pause |
string | Pause schedule between batches (cron style). Basically unused for self-healing |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 733 lines · 168 tokens per session scan E afd7bbc2089b
modify-task-tpl is a skill published in the GitHub repository ccfos/nightingale (13,395 stars, last pushed yesterday), licensed Apache-2.0. It adds 168 tokens to every session and 7,747 once invoked, about $0.0007 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
cis-aws-database-10.8
Ensure Monitoring and Alerting is Enabled.
monitoring-expert
Expert-level monitoring and observability with Prometheus, Grafana, logging, and alerting. Use when the user mentions observability, Prometheus, Grafana, logging, metrics, or alerting, or when the task involves The Three Pillars of Observability, Monitoring Fundamentals, Prometheus Configuration, or Alert Rules.
prometheus-expert
Expert-level Prometheus monitoring, metrics collection, PromQL queries, alerting, and production operations. Use when the user mentions monitoring, metrics, observability, alerting, or PromQL, or when the task involves Prometheus Architecture, Installation on Kubernetes, ServiceMonitor, or PromQL Queries.
k8s-monitoring-alerting
A Kubernetes diagnostic and repair method for Prometheus and Grafana monitoring problems, including alerts that do not trigger. Prometheus collects measurements, while Grafana displays them in dashboards.
datadog
Full-stack observability with Datadog APM, logs, metrics, synthetics, and RUM. Use when implementing monitoring, tracing, alerting, or cost optimization for production systems.
observability-testing-patterns
Observability and monitoring validation patterns for dashboards, alerting, log aggregation, APM traces, and SLA/SLO verification. Use when testing monitoring infrastructure, dashboard accuracy, alert rules, or metric pipelines.