radaromega-pro

Files (1)

• SKILL.md

SKILL.md (first lines)

# radaromega-pro

Read `skills/radaromega/reference/signs.md` alongside this whenever the question is *what is about to happen* rather than what is happening — this file is how to drive the app, that one is what to look for and how much lead time each sign is worth.

The field-tested companion to the base `radaromega` skill. That one has philosophy and output rules; this one is ground truth: which tools actually work, the exact JS recipes that replace the broken ones, where each kind of data really lives, and what a professional meteorologist would show for each question type. Verified live 2026-06-10 across radar, model, fronts, warnings, tropical, MRMS, and data tools; satellite re-audited and product/mode inventories re-derived 2026-09-03. Trust this over the base skill where they disagree.

## 1. Tool reliability table (reconciled by the operator 2026-06-10 ~05:20)

The tools this skill originally flagged broken were REBUILT from these very recipes and verified live — **use the tools first**; they run the §3-§5 protocols internally. The recipes below remain the fallback if a tool ever contradicts the screen.

| Tool | Status |
|---|---|
| `set_model` | FIXED — loads newest run + ALL frames, returns run id + stepRange (§3 protocol inside) |
| `set_forecast_hour` | FIXED — engine stepChanged, snaps to available step, returns validTime |
| `set_model_product` | FIXED — selector-first ordering, reload, holds step |
| `change_radar_site` | FIXED — activateTowerByCode + waits for data |
| `capture_loop(advance:'hours')` | model run as video, steps real step values |
| `capture_loop(advance:'playback')` | FIXED 2026-08-10 — loads history and steps real sweeps; errors instead of shipping a frozen clip (§6) |
| `sample_radar_values(points)` | NEW 2026-08-10 — exact dBZ/m·s at lat/lons, with beam height (§5a-bis) |
| `scan_radar_field(...)` | NEW 2026-08-10 — ranked cores, or gate-to-gate velocity couplets (§5a-bis) |
| `get_outlooks(lat, lon, day, include_text)` | NEW 2026-08-10 — SPC outlooks from the app's own layer, point-tested (§5a-ter) |
| `get_mesoscale_discussions(lat, lon)` | NEW 2026-08-10 — MCDs with prob_of_watch (§5a-ter) |
| `fit_view(points, padding_px, max_zoom)` | NEW 2026-08-10 — solves the zoom so the storm fills the frame. Use instead of a guessed `fly_to` zoom before ANY capture (§6a) |
| `change_radar_product` | FIXED 2026-08-10 — validates against the LIVE selector and lists real codes; codes are HCC/DRF/HSV/HSW, and there is no DVIL (§6b) |
| `scan_radar_field(mode:'couplet')` | now REFUSES on a non-velocity sweep instead of calling reflectivity edges "rotation" (§5a-bis) |
| `get_warnings(filter?)` / `get_warning_details(warning_id)` | FIXED — read the §5b in-app cache directly (census, tornado/hail/wind tags, damage threat, emergency flag, raw bulletin) |
| `get_nhc_data` | FIXED — reads nhc.activeTropicalData (§4b); rendering cone/track still via §4b recipe |
| `get_storm_reports(day?)` | FIXED — fetches SPC reports CSV itself |
| `get_metar_data(ids?)` | FIXED — fetches aviationweather.gov (ids or current-view bbox) |
| `get_lightning_data` | router — but it is WRONG that no feed exists: GOES **GLM total lightning is in the app** and readable as numbers (§4f) |
| `measure_distance` | FIXED — haversine, no turf needed |
| `toggle_overlay('surfaceFronts')` | still no toggle — fronts recipe (§4) |
| `get_radar_info` | still nulls sometimes — `get_map_state` / `get_model_state` |
| SATELLITE view | **WORKS** (re-audited 2026-09-03) — all 16 ABI bands, GeoColor/Day-Land-Cloud/Fire RGBs, meso sectors, loops. The old "no imagery" row was wrong; see §4c |
| `show_feature('severe_weather_outlooks')` | polygons unreliable for DISPLAY — but the data is there; read it with `get_outlooks` (§5a-ter) |

**Also trustworthy:** `execute_js`, `capture_view`, `capture_loop`, `fly_to`, `set_view_mode` (RADAR/MODEL/MRMS/**SATELLITE**), `change_radar_product` (drives radar AND satellite products), `get_model_state`, `get_map_state`, `control_animation`, drawing tools (coords are [lng,lat]), `close_panels`.

**Two that mislead rather than fail:** `get_page_text` returns empty — don't reach for it. `get_detailed_state` reports `viewMode: "RADAR"` while satellite is genuinely displayed.

**execute_js must go through the iframe.** App content lives in `window.frames[0].document`; a top-level `document.getElementById` returns null and reads exactly like "the app doesn't have that". `window[0] || window` is the same thing for the globals.

**Standing watches:** "tell me when X happens" → `set_trigger` (you author a URL or in-app JS probe + a predicate; the daemon checks for free and wakes you ONLY on fire, with the data). Missions wake you every check — use them only when each check needs judgment.

If radaromega tools start failing schema validation mid-session, the MCP server reconnected — reload via `ToolSearch "select:mcp__radaromega__execute_js,..."` and retry once.

**execute_js gotchas:** the param is `expression`, not `code`. And awaiting a slow app callback inside an async IIFE can die with CDP "Promise was collected". For long loads use the window-flag pattern: kick off `mod.loadX(() => { window.__flag = true })` in one call, then poll `window.__flag` / frame counts in a second call.

## 1b. Wedged engine — the TOOLS now self-heal (hardened by the operator 2026-06-10)

After long app uptime the model engine corrupts (callbacks never fire, view switches silently no-op, `precomputedStepData` goes null). You no longer fix this yourself: `set_model` and `set_view_mode` DETECT the wedge, restart the app, and retry automatically — a recovered call returns a `recovered:` note and takes ~15-20s instead of ~3s. `set_view_mode` also returns `verified: true` only when a readback proves the app really switched (preferences and the dropdown both lie when wedged; the PRODUCT_SELECTOR option list is ground truth — *-DATA = model/mrms, HRF/HVL/... = radar).

If `set_forecast_hour` or `set_model_product` report "engine was wedged — RESTARTED automatically", the loaded run is gone: call `set_model` again, then retry. Do NOT drop into execute_js debugging for any of these symptoms — one more `set_model` call is always the answer.

Related: `w.MODE_SELECTOR` is the master mode dropdown (options: 0/RADAR/MRMS/HRRR/NAM3KM/NAM12KM/RAP/GFS/ECMWF/HWRF/HMON/SATELLITE/NDFD — models ARE modes). Manual fallback for a stuck mode switch: `w.MODE_SELECTOR.val('HRRR').trigger('change')`. `capture_loop(advance:'hours')` reads the run loaded by `set_model` (it now also sees runs loaded by hand via activeSteps, but tool-loaded runs are the reliable path).

## 2. App internals map (what execute_js drives)

- Master object: `window.__claude_map` — a Mapbox map extended with mode controllers: `.radar`, `.satellite`, `.mrms`, `.model`, plus `.mode` (current view).
- **Decoded radar values** live at `.radar.radarRenderer.sweep` (§5a) and the tower's lat/lon at `.radar.radarRenderer.tower`.
- **Subsystems with no MCP tool** (classes on `w`, instances usually hanging off the map): `NexradAttributeTracks` (§5b-2), `LightningDetectionMapbox` / `RapidStrikeMapbox` / `LightningFlashDensityRendererMapbox` (strike feeds — `determineApiUrl` / `getApiUrlForRadar` give the endpoints), `SevereWeatherOutlooksMapbox` + `fetchGeoJSONOutlook`, `MesoscaleDiscussionsMapbox` (the `mesoscale-discussions` map source already carries the SPC MD `full_text`), `StormReportsMapbox`, `StormNetMapbox` (spotters), `HydrologicalOutlooksMapbox`, `WinterWeatherOutlooksMapbox`, `PeakStormSurgeMapbox`. When something seems missing, enumerate `Object.keys(w)` against a regex before concluding the app does not have it.
- App globals live in the iframe: `const w = window[0] || window` → `w.MODELS_REGION_SELECTOR` ('2'=CONUS, '12'=GLOBAL), `w.MODELS_DATE_HOUR_SELECTOR` (options "YYYY-MM-DD|HH", FIRST = latest run), `w.PRODUCT_SELECTOR` (shared across RADAR, MODEL and MRMS modes — its option list tells you which mode the app is REALLY in: HRF/HVL/... = radar, *-DATA = model/mrms), `w.STEP_SELECTOR`, `w.MODELS_DATE_SELECTOR` + `w.MODELS_HOUR_SELECTOR` (the pair the engine actually reads in computeModelStepData), `w.MODELS_VALID_TIMESTAMP`, `w.MODE_SELECTOR` (§1b), `w.surfaceFronts`, `w.nhc`, `w.hurricaneHunter`, `w.spaghettiModels`, `w.nexradHistory`, `w.RADAR_TOWER_CODE`.
- Radar controller useful methods: `activateTowerByCode(code, product, bool)` (NOTE: activATE, not active — it's on `.radar`, not the map), `activateClosestTower()`, `getActiveTower()`, `getActiveProduct()`, `productChanged`, `stepChanged`.
- `model.activeSteps` is an Object keyed by step number, NOT an array — `Object.keys(md.activeSteps)`; `.slice()` throws.
- Model engine call chain (for debugging): `runModel(cb)` fetches run metadata into `previousModelData` and REPOPULATES the product/date/hour selectors (wiping your selections — re-set them after); `hourSelected()` → `computeModelStepData(cb)` reads MODELS_DATE_SELECTOR/MODELS_HOUR_SELECTOR/PRODUCT_SELECTOR, and **silently returns without calling cb** if `getModelStepData(product)` is null; `loadScans` fetches the S3 frame JSONs (sdsweather-public.s3.amazonaws.com/images/models/...) and clears+refills `activeSteps`.

## 3. Model view recipes (the big one)

Enter with `set_view_mode('MODEL')` (works). Then everything below in `execute_js`.

**Switch model + load latest run + render frame N:**
```js
(async () => {
  const w = window[0] || window;
  const md = window.__claude_map.model;
  md.activeModel = 'HRRR';              // HRRR | NAM3KM | NAM12KM | RAP | GFS | ECMWF
  w.MODELS_REGION_SELECTOR.val('2');
  await new Promise(res => md.runModel(res));
  const dh = w.MODELS_DATE_HOUR_SELECTOR;
  dh.val(dh.find('option').first().val());      // latest run
  md.sweepsLoaded = false;
  md.hourChanged();
  await new Promise(res => md.preloadData(res)); // REQUIRED or map renders blank
  md.stepChanged(14);
  return JSON.stringify({model: md.activeModel, run: dh.val(), steps: Object.keys(md.activeSteps).length});
})()
```
Verify with `get_model_state` and READ THE RETURNED validTime — never do step→hour arithmetic. Then `capture_view(settle_ms: 2000)`. If callbacks never fire or activeSteps won't update: §1b, restart.

**Switch product** (selector FIRST or preloadData reverts to COMPREF):
```js
(async () => {
  const w = window[0] || window;
  const md = window.__claude_map.model;
  w.PRODUCT_SELECTOR.val('MAXUPDH-DATA');
  md.productChanged('MAXUPDH-DATA');
  md.sweepsLoaded = false;
  await new Promise(res => md.preloadData(res));
  md.stepChanged(14);
})()
```
Products end in `-DATA`. Re-enumerated from the live HRRR selector 2026-09-03:
COMPREF (sim radar), MAXUPDH (updraft helicity = rotation; blank over an area = no organized severe),
SFCCAPE, MUCAPE, CAPE03, SCIN, MCIN, SCP, STP, EHI1KM, EHI3KM, SRH1, SRH3, BLK1, BLK6 (bulk shear),
2MTEMP, 2MDEWPOINT, 10MW, 10MWG (gusts), MSLP, 700T, 850T, 500W, 700W, 850W,
PTYPE, TPRECIP, TSNOW, TFRZR, TFRZRA.
**There is no TOR, WIND, HAIL or TSNOWKUCH** — those were in this file for months and the app rejects them.

**The product list shrinks as the model gets coarser, and that decides which model you must be on.**
Enumerated live 2026-09-03: HRRR carries the full severe suite; NAM12KM drops MAXUPDH, MUCAPE, CAPE03,
EHI1KM, SRH1 and BLK1 (24 products); GFS in GLOBAL region is down to 17 and also loses STP, SRH3, SCIN,
MCIN and BLK6. So **updraft helicity and the 0-1 km ingredients only exist on the convection-allowing
models** — asking GFS for MAXUPDH is not a code error, the field is not there. Note GFS defaults to the
GLOBAL region (`w.MODELS_REGION_SELECTOR`, '2'=CONUS / '12'=GLOBAL); switch to CONUS before concluding
a product is missing. Read the selector when a code is refused rather than trusting any table, including
this one.

**Model run as VIDEO** (the money deliverable for "what do the models show"): after preload, `capture_loop(advance:'hours', frames:N, start_step:1, step_stride:S, format:'mp4', interval_ms:700)` — returns the mp4 path + final valid time. NAM3KM: 60 hourly steps → frames:30, stride:2 covers 2.5 days. HRRR synoptic runs (00/06/12/18Z) go 48h, off-cycle only 18h. GFS 3-hourly to 150+.

From Deibler/edmund-harness, MIT.

More from Deibler/edmund-harness