Skill: wroadd/alert-triage (version 1.0.1)

--- name: alert-triage description: Normalize noisy notifications into a simple triage model: send now, batch later, ignore, suppress as duplicate, or escalate. Use when the user wants to reduce alert fatigue, deduplicate alerts, route notifications by severity or audience, define quiet hours, create digest policies, decide what deserves paging, or design an OpenClaw-first alert policy without binding to a specific sender or monitoring vendor. --- # Alert Triage Use this skill to turn a stream of alerts into a clear policy and response model. ## Core principle Do not start with channels or tools. Start with the decision. For each alert, decide: 1. Is it actionable? 2. Is it urgent? 3. Is it trustworthy? 4. Is it new information? 5. Who actually needs it? 6. Should it be immediate, batched, suppressed, ignored, or escalated? ## Output model Classify each alert into one of these outcomes: - **send-now** - **batch-later** - **ignore** - **suppress-as-duplicate** - **escalate** When helpful, also assign: - severity: `critical | high | medium | low | info` - confidence: `high | medium | low` - audience: `operator | owner | team | system` - timing: `immediate | next-digest | business-hours | maintenance-window` ## Workflow ### 1. Normalize the signal Convert the raw notification into a compact event record: - source type - event summary - likely impact - affected system or workflow - first seen time - repeat count if known - current evidence If the source is noisy or ambiguous, rewrite it into one sentence before classifying it. ### 2. Check actionability Ask: - Can someone do something useful now? - Does delay make the outcome materially worse? - Is there a clear owner or audience? If not actionable, prefer `ignore` or `batch-later`. ### 3. Score urgency Urgency increases when: - revenue, uptime, data safety, or customer experience is at risk - the problem is time-sensitive or irreversible - the signal indicates active degradation, not just a threshold crossing - the event affects many users or critical workflows Urgency decreases when: - the event is informational only - the issue is self-healing or reversible - the metric fluctuation is within normal variance - the event is outside service relevance or ownership ### 4. Check trust and evidence Before escalating, check whether the alert is: - from a trustworthy source - supported by more than one signal - already acknowledged elsewhere - likely a false positive or transient blip Low-trust alerts should usually not page people unless impact is potentially severe. ### 5. Deduplicate and suppress Treat an alert as a duplicate when it repeats the same underlying issue within the same suppression window. Use a suppression key based on the smallest stable combination that identifies the problem, for example: - source - affected component - error family - environment - severity bucket Suppress duplicates when the new event adds no meaningful information. Do **not** suppress when the event shows: - a severity increase - wider blast radius - longer duration than expected - a new affected component - failure of a previous recovery attempt ### 6. Route by audience Route based on who can act, not who might be interested. Default pattern: - `critical` and actionable, immediate owner plus escalation path - `high`, owner or operating team quickly - `medium`, working queue or next digest unless time-sensitive - `low` and `info`, digest or ignore ### 7. Apply timing policy Use timing rules such as: - immediate if impact is active and delay is costly - next digest if useful but not urgent - business hours if action can safely wait - maintenance window if the alert is expected during change work Quiet hours should reduce noise, but not hide critical actionable events. ### 8. Produce final policy output Return a concise table or bullet list with: - normalized alert - severity - final outcome - audience - timing - rationale - suppression key or digest bucket when relevant ## Recommended output template ```markdown ## Alert triage result | Alert | Severity | Outcome | Audience | Timing | Reason | |------|----------|---------|----------|--------|--------| | [normalized alert] | high | send-now | operator | immediate | customer-facing outage with clear action | | [normalized alert] | low | batch-later | owner | next-digest | useful trend, no urgent action | | [normalized alert] | medium | suppress-as-duplicate | system | current window | same root issue, no new information | ``` ## Decision heuristics Prefer **send-now** when all are true: - actionable - time-sensitive - trusted enough - meaningful impact Prefer **batch-later** when: - action exists, but delay is acceptable - the alert is useful as pattern context - the event is better understood in aggregate Prefer **ignore** when: - no action is needed - the event is vanity noise - the source is too weak without corroboration Prefer **suppress-as-duplicate** when: - it is the same incident inside the suppression window - nothing important changed Prefer **escalate** when: - severity increased - the response owner did not act in time - business impact crossed a threshold - the event exceeded duration or repetition limits ## Privacy and portability rules Keep outputs reusable and marketplace-safe. Do not include: - personal phone numbers - private email addresses - real user names - internal channel IDs - device nicknames - company secrets - private endpoints or tokens Use abstract placeholders instead: - `primary-on-call` - `ops-channel` - `business-owner` - `customer-alerts` - `critical-systems` ## References Read these when needed: - `references/policies.md` for reusable policy patterns - `references/examples.md` for worked examples

path: references/examples.md
content: # Worked examples for alert-triage

## Example 1: customer-facing outage

### Input
"Checkout API error rate exceeded 20% for 6 minutes across production."

### Triage
- severity: critical
- outcome: send-now
- audience: operator
- timing: immediate
- reason: active customer impact with clear need for rapid intervention

## Example 2: repetitive background job failures

### Input
"Nightly export job failed again. Same error signature as previous 4 alerts in the last 30 minutes."

### Triage
- severity: medium
- outcome: suppress-as-duplicate
- audience: system
- timing: current window
- reason: same underlying issue, no new information beyond repetition count

## Example 3: billing sync lag

### Input
"Billing sync is delayed by 18 minutes but recovering. No failed invoices yet."

### Triage
- severity: medium
- outcome: batch-later
- audience: owner
- timing: next-digest
- reason: useful and actionable, but not urgent while recovery is in progress and no downstream damage is present

## Example 4: vanity metric movement

### Input
"Homepage traffic is down 4% compared with the same hour last week."

### Triage
- severity: info
- outcome: ignore
- audience: system
- timing: none
- reason: low-signal fluctuation with no clear immediate action

## Example 5: escalation trigger

### Input
"Primary responder did not acknowledge the production database failover alert within 10 minutes."

### Triage
- severity: critical
- outcome: escalate
- audience: operator
- timing: immediate
- reason: response policy breached on a critical service issue

## Example 6: digest-worthy alert cluster

### Input
"Five low-priority content publishing warnings occurred across different jobs between 01:00 and 05:00. All retries succeeded."

### Triage
- severity: low
- outcome: batch-later
- audience: owner
- timing: morning-digest
- reason: useful pattern signal, but interruptions are unnecessary because recovery succeeded


path: references/policies.md
content: # Policy patterns for alert-triage

## 1. Severity model

### Critical
Use when there is active business, safety, revenue, or major uptime impact and immediate action is justified.

### High
Use when there is material degradation, rising risk, or likely near-term impact that should be handled quickly.

### Medium
Use when the issue is real and actionable, but safe to queue or batch unless it persists.

### Low
Use when the event is mildly useful, low-risk, or operationally routine.

### Info
Use when the event is mainly informational and should usually go to digest or be ignored.

## 2. Outcome policy

### send-now
Use for urgent, trusted, actionable alerts.

### batch-later
Use for non-urgent but decision-useful signals.

### ignore
Use for vanity metrics, low-signal noise, and non-actionable events.

### suppress-as-duplicate
Use when repeated events add no meaningful new information.

### escalate
Use when ownership failed, impact widened, or duration exceeded policy.

## 3. Suppression windows

Typical starting ranges:
- transient infra noise: 5 to 15 minutes
- repeated app errors: 15 to 60 minutes
- recurring business workflow failures: 30 to 120 minutes
- digest-only info events: one digest bucket per period

Tune windows based on how often new information actually appears.

## 4. Digest policy patterns

### Hourly digest
Use for operational updates that matter during the day but do not justify interruptions.

### Morning digest
Use for overnight low-priority events, trends, and summary metrics.

### End-of-day digest
Use for leadership or owner summaries focused on decisions, not raw noise.

A good digest should group by:
- system or workflow
- repeated root cause
- trend direction
- action needed

## 5. Routing policy patterns

### Operator-first routing
Best for incidents where a technical responder can act directly.

### Owner-first routing
Best for business workflow alerts, approvals, or commercial impact.

### Team digest routing
Best for shared situational awareness without interrupting anyone.

### Silent system routing
Best for machine-only acknowledgement, counters, or incident correlation.

## 6. Quiet hours policy

Quiet hours should suppress low-value interruptions, not hide urgent failures.

Suggested rule set:
- critical plus actionable bypasses quiet hours
- high severity may wait until business hours unless customer-facing
- medium, low, and info default to digest during quiet hours

## 7. Escalation policy

Escalate only on explicit conditions, for example:
- no acknowledgement within defined time
- repeated failure beyond retry budget
- severity rises from medium to high or high to critical
- customer impact crosses threshold
- issue duration exceeds tolerated window

## 8. Anti-fatigue rules

- Prefer one good alert over ten noisy ones
- Aggregate repeated failures into one evolving incident
- Suppress vanity thresholds with no action path
- Review false positives and downgrade or remove them
- Route to the smallest audience that can act


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)