radaromega

Files (9)

• SKILL.md
• signs.md · reference/
• cammap.py · scripts/
• cells.py · scripts/
• ground_truth.py · scripts/
• panel.py · scripts/
• radar_query.js · scripts/
• report.py · scripts/
• sounding.py · scripts/

SKILL.md (first lines)

# radaromega

RadarOmega is **the** weather workflow — not just severe weather. Current
conditions, "will it rain tomorrow", forecasts, radar, models, alerts, tropical,
winter, fire, marine, hydro, power outages: all of it starts here. Supplement
with `api.weather.gov` (via curl, with a User-Agent header) for text forecasts
and alert polling — never any other weather source.

Three companion documents, in the order you reach for them:

- **`reference/signs.md`** — the convective-signs ladder. Read it for any
  "what is going to happen" question. Radar can only describe the present;
  that file is how you get 30-90 minutes of honest lead time.
- **`skills/radaromega-pro`** — tool reliability, execute_js recipes, app
  internals, data routing. Read WITH this skill before any real weather work.
- **`scripts/`** — `sounding.py`, `cells.py`, `ground_truth.py`, `panel.py`,
  `report.py`, `cammap.py`, `radar_query.js`. Documented in radaromega-pro §5c/§6b.

## Reliability — what you can assume

- **Every tool self-heals.** No connect/discover step: each tool auto-attaches
  and even auto-launches the app if it's closed (a cold first call takes ~10-45s
  — send a quick "pulling up radar" first if the user is waiting). Tools never
  hang; they error clearly.
- **Wedged engine auto-recovers.** If the app has been up a long time and the
  model engine corrupts, `set_model` / `set_view_mode` detect it, restart the
  app, and retry by themselves (~15-20s, result carries a `recovered:` note). If
  `set_forecast_hour`/`set_model_product` say the app was restarted, just call
  `set_model` again — NEVER drop into execute_js debugging for engine weirdness.
- "Stuck on a login or update screen" error → tell the user the app needs a
  manual look; don't retry-loop.
- **Don't `sleep` in Bash.** Navigation tools wait for data themselves:
  `change_radar_site` (default 5s settle), `change_radar_product` (3.5s), and
  `capture_view(settle_ms: …)` covers the rest.
- **`get_detailed_state` lies about the mode.** It reports `viewMode: "RADAR"`
  while satellite imagery is genuinely on screen. Trust `get_map_state`, the
  product selector's option list, or your own eyes on a capture.

## Images & video — clean by default

- `capture_view` returns the **clean map** — data, warnings, your drawings, ZERO
  app UI. That's what the user gets. Full-res goes to the sandbox for
  `send_attachment`; by default only the saved path comes back (no inline image).
  Pass `view: true` on captures you need to eyeball yourself — you get a
  downscaled inline copy (don't re-capture to "get a better look" — the saved
  file is sharp). Captures you're only delivering to the user don't need `view`.
- `capture_view(include_ui: true)` ONLY when you need to see the app's interface
  to operate it. Never send include_ui shots to the user.
- `capture_loop(frames?, interval_ms?, format?)` — the animation as a clean mp4
  (plays inline in iMessage) or gif. The single best way to show motion: an
  approaching line, rotation, a model run, **a satellite loop of a building
  cumulus field**. Works in RADAR, MRMS, MODEL and SATELLITE modes.
- `close_panels` — Escape + close-buttons when a settings panel covers the map.

## Don't spam the user

One reply = **the one or two visuals that tell the story**, with your read as the
caption. Run your full analysis pass silently (reflectivity, velocity, dual-pol,
satellite, whatever it takes — `capture_view(view: true)` on frames you are
reading yourself), then send the best frame plus maybe one loop. Eight separate
product screenshots is a slideshow, not an answer. Exception: the user explicitly
asks to see each product.

## Label like a meteorologist — always

Before sending an analysis image, annotate it (`clear_drawings` first, then draw,
then capture):

- Mark **what** and **where**: hail cores, rotation couplets, the user's
  location, outflow boundaries, overshooting tops, threat polygons, motion vectors.
- Use real terminology and translate the so-what: "bow echo", "hook echo",
  "training cells", "TVS", "gust front", "overshooting top", "above-anvil cirrus
  plume" — then "that hook near Lititz is rotation, be on the basement side by 9:40".
- Captions state: what's happening, where it's going, when it arrives, what to do.
- `clear_drawings` and restore the home radar view when done with a remote event.

---

## Tool surface (verified arg names, product codes verified live 2026-09-03)

**Navigate** — `fly_to(lng, lat, zoom?)` (note `lng`), `fit_view(points, …)`
(use this instead of a guessed zoom before any capture), `measure_distance`.

**Modes** — `set_view_mode(RADAR|SATELLITE|MRMS|MODEL)`. The app's master
dropdown also carries `NDFD` and the model names directly, but the tool enum
does not; for NDFD see the recipe below.

### RADAR products — `change_radar_product(product)`

`HRF` reflectivity (also HRF2/3/4 for higher tilts of the *composite* product
set), `HVL` velocity (HVL2/3/4), `HSV` storm-relative velocity, `HSW` spectrum
width, `HCC` correlation coefficient, `DRF` differential reflectivity (ZDR),
`KDP` specific differential phase, `HCA` hydrometeor classification, `DAA` dual-pol
accumulation, `OST` one-hour storm total, `STP` storm total precip, `VIL`,
`ETP` echo tops, `WINTER_EXP`.

There is **no** `CC`, `ZDR`, `SHR`, `BRF`, `BVL` or `DVIL` — those are the codes
you would guess and the app rejects them. It validates against the live selector
and lists the real codes back at you; take the list it gives over this file.

**The elevation is fixed at the 0.5° base tilt.** There is no tilt control, so
BWER, storm-top divergence, descending reflectivity cores and ZDR *column depth*
are not available here. Vertical information comes from the derived products
(`VIL`, `ETP`) and from MRMS.

`change_radar_site(siteCode)` — waits for data itself. Pick the tower with the
**lowest beam** over the point in question, not the nearest by map distance.

### SATELLITE — works, and the old skill said it didn't

`set_view_mode("SATELLITE")`, then drive the product with **`change_radar_product`**
(yes, that tool — it writes the shared product selector, which in satellite mode
holds satellite codes):

- `GEOCOLOR-DATA` — day/night composite, the default look
- `NATCOLOR-DATA` — Day Land Cloud RGB. Ice cloud/snow renders **cyan**, water
  cloud dull grey/white. Daytime only. The app's stand-in for Day Cloud Phase.
- `FIRETEMP-DATA` — fire temperature RGB
- `BAND01-DATA` … `BAND16-DATA` — all sixteen ABI bands

From Deibler/edmund-harness, MIT.

More from Deibler/edmund-harness