# Alarm

> Alarm and resource health skill. List and analyze alerts, collect component-model-driven resource monitoring evidence for LLM health analysis, and perform alert status operations.

- Skill: `cloudchef/alarm` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add cloudchef/alarm`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cloudchef/alarm/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: CloudChef (https://skillmd.com/u/cloudchef)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cloudchef/alarm

---


# alarm

Alarm and resource-health workflow for triggered alert retrieval, rule-aware
alert analysis, component-model-driven resource health evidence, and status operations.

## Purpose

Provide alarm-management capabilities:
- List triggered alerts with machine-readable metadata
- Resolve one exact resource and distinguish current firing/muted alerts from currently resolved alerts triggered within the configured lookback for comprehensive resource analysis
- Analyze one alert with normalized facts, datasource-enriched resource context, assessment, and remediation guidance
- Analyze one resource independently of alerts by handing component-specific monitoring evidence to the LLM
- Perform validated status operations (`mute`, `resolve`, `reopen`)

## Handlers and helpers

`scripts/adapter.py` contains the four Tool handlers: `list_alerts`,
`analyze_alert`, `analyze_resource_health`, and `operate_alert`. It converts
AtlasClaw Context and Tool parameters, then calls SmartCMP Provider.

`scripts/_alarm_object_actions.py` remains separate because the embedded
assistant Context resolver calls it to build alert page actions. It is not a
one-command forwarding script.

## Workflow

See [references/WORKFLOW.md](references/WORKFLOW.md) for the supported workflow.

## Resource Enrichment

During alert analysis, the Adapter uses SmartCMP Provider resource
resolution when the alert exposes `entityInstanceId` or `nodeInstanceId`.

- Resolve related SmartCMP resources before finalizing the analysis narrative.
- Merge normalized `type + properties` resource facts into the alert analysis payload.
- If resource lookup is unavailable, continue the alert analysis with alert and
  policy facts, and treat resource enrichment as best-effort context.

## Resource Health Analysis

Resource health analysis is independent of alert analysis:

- Resolve the resource through datasource resource helpers and use its normalized `componentType`.
- Load the effective monitoring model for that component; never substitute a generic VM metric list.
- Query only PromQL that can be scoped to the resolved resource through model-declared labels and exporter identity.
- Emit descriptive statistics and monitoring coverage, but leave `healthy`, `abnormal`, or `indeterminate` judgment to the AtlasClaw LLM.
- The final LLM response must include status, confidence, principal findings, metric evidence, missing evidence, and recommended actions.
- Treat disabled, unavailable, or missing monitoring as an evidence gap rather than proof that the resource is healthy or unhealthy.
- Do not read active alerts or alarm-policy thresholds for the resource-health conclusion.

## Resource Alert Evidence

Resource alert evidence complements, but never changes, the independent health
contract above.

- Call `smartcmp_list_alerts` with the same exact resource target used by the other comprehensive analysis tools.
- `current_and_recent` queries current `ALERT_FIRING` and `ALERT_MUTED` alerts without a trigger-time limit, then queries alerts whose current status is `ALERT_RESOLVED` and whose `triggerAt` is within the last seven days. SmartCMP does not expose a `resolveAt` range in this search contract, so this must not be described as “resolved during the last seven days.”
- Resolve the target to SmartCMP `Resource.id`, pass it through the exact `targetEntityId` query parameter, and verify the same field in every returned alert.
- Do not use the resource name, `nodeInstanceId`, or `entityInstanceId` as resource-association evidence.
- Read `##RESOURCE_ALERT_COVERAGE_START##` before concluding that no alert was observed. `partial` or `indeterminate` association means the alert dimension is unknown.
- If the same alert is observed as current and resolved across the two requests, preserve both observations and treat the lifecycle race as `partial` evidence.
- Absence of a matched alert is not monitoring-health evidence and must not be used to upgrade an `indeterminate` health conclusion.