Storm Watch

---
name: storm-watch-v2
description: On-demand storm monitoring skill that watches a weather event for a specified location and time window, sends alerts only when conditions materially change, and stops automatically at the end of the watch period.
version: 1.0.0
author: Herman + Dan
---

# Storm Watch v2

Monitor a storm affecting **{{location}}** and deliver meaningful updates until **{{end_datetime}}**.

Use this skill when the goal is not to send fixed-schedule weather spam, but to answer: **has the storm outlook changed enough that the user should know right now?**

This skill is **on-demand**, not a standing recurring digest. It is triggered when the user asks to watch a specific storm for a limited time window.

## When to use this skill

Use it when the user wants:

- storm monitoring for a specific place
- snowfall / severe thunderstorm / tornado / flooding updates
- alerts over a specific watch window such as `now until 10pm`
- smart updates only when the forecast materially changes
- automatic stop/cleanup when the monitoring window ends

## When not to use this skill

Do **not** use it when the user wants:

- a normal daily forecast
- a single one-time weather summary with no continued tracking
- minute-by-minute radar commentary
- updates with no meaningful threshold for change
- permanent monitoring with no end time

## Required parameters

- `{{location}}` — city / county / region being monitored
- `{{end_datetime}}` — when the watch should stop
- `{{delivery_channel}}` — where updates should be delivered
- `{{check_interval}}` — e.g. every 30 minutes or every 60 minutes
- `{{storm_type}}` — e.g. snowstorm, severe thunderstorms, hurricane remnants, flooding risk
- `{{meaningful_change_rules}}` — thresholds that justify an alert

## Defaults

If the user does not specify everything:

- default check interval = **hourly**
- use **30-minute checks** for fast-moving severe weather
- require a clear end time
- if the location is vague, resolve it before scheduling

## Setup pattern

Use these files in the skill directory or local working area:

- rolling state file: `storm-watch-state.json`
- optional notes/reference file: `storm-watch-notes.md`

See:
- `examples/storm-watch-state.example.json`
- `references/scheduling-pattern.md`

## State model

Track at minimum:

- `location`
- `storm_type`
- `watch_start`
- `watch_end`
- `check_interval_minutes`
- `last_checked_at`
- `last_sent_at`
- `last_forecast_snapshot`
- `last_alert_summary`
- `active` boolean

The state file should stay compact and only hold what is needed to compare the current forecast to the previous one.

## Core workflow

1. Resolve the location and watch window.
2. Initialize the state file before scheduling checks.
3. Create scheduled checks across the requested time window.
4. On each run, fetch current forecast / warning information from the best available source.
5. Compare the current forecast to `last_forecast_snapshot`.
6. Send an alert only if a meaningful threshold is crossed.
7. Update the state file whether or not an alert is sent.
8. Mark the watch complete and clean up when the window ends.

## Meaningful change rules

Send an update only when **something materially changed** since the prior alert/check.

Examples for snow:
- total snowfall forecast changed by at least `{{snow_change_threshold}}`
- change in peak timing by at least `{{timing_change_threshold}}`
- warning upgraded or downgraded
- road / travel hazard framing changed meaningfully

Examples for severe storms:
- tornado watch / warning issued, upgraded, or canceled
- severe thunderstorm warning issued, upgraded, or canceled
- flood watch / warning issued, upgraded, or canceled
- storm arrival timing shifts materially
- hazard level changes meaningfully (wind / hail / tornado / flooding risk)

Examples for tropical / broad storm systems:
- cone / track shift materially changes local impact
- rain / wind / surge / flood expectations cross a new threshold
- emergency declarations or evacuation language appears

## Suppression rule

If nothing meaningful changed:

- do **not** deliver a user-facing alert
- still update `last_checked_at`
- optionally record a short no-change note in state

This suppression behavior is a core part of the skill.

## Forecast sourcing

Prefer sources in this order when available:

1. National Weather Service / official government point forecast and alerts
2. Official weather alert / emergency management sources
3. High-quality local weather coverage
4. Broad news coverage only as supporting context

Prefer the most local and most current source.

## Scheduling model

This skill can be implemented with either:

- one recurring temporary cron job that checks state and stops at `{{end_datetime}}`, or
- multiple one-shot scheduled jobs across the window

Either approach is acceptable as long as:

- the watch ends automatically
- checks do not continue after `{{end_datetime}}`
- alert suppression works correctly
- duplicate catch-up runs are avoided

## Output format for alerts

```text
⚠️ Storm Update — [time]
[2-4 concise sentences: what changed, current expectation, timing, and what matters now]
📍 {{location}}
Source: [primary source]
```

## Final update

The final scheduled update should clearly indicate that the watch is ending, for example:

```text
⚠️ Storm Update — Final for tonight
```

It should summarize:
- final expected totals / impacts
- when the storm hazard should taper off
- any next-morning carryover risk if relevant

## Style constraints

- Keep alerts short and practical.
- Lead with what changed.
- Avoid repeating the same forecast wording if nothing material changed.
- Prefer consequence over meteorological filler.
- Write for someone checking their phone quickly.

## Success criteria

A good Storm Watch setup should:

- feel quiet when the forecast is stable
- feel fast when a real change happens
- avoid duplicate or meaningless alerts
- stop automatically at the requested end time
- make the user feel informed, not spammed