Skill

Radar and Satellite Analysis

Analyzes radar and satellite weather products as remote-sensing observations, separating direct measurements from meteorological inference.


90
Spark score
out of 100
Updated 28 days ago
Source checked Sep 26, 2026
Version 18.5.0

Add to Favorites

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-radar-satellite-analysis | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Radar and Satellite Analysis

Interprets already-decoded radar and satellite weather products as remote-sensing observations, keeping direct measurement, derived proxy, and meteorological inference explicitly separate with stated uncertainty. Use after radar or satellite data is already retrieved and decoded, when interpreting storm structure, tracking evolution, or building a nowcast; not for fetching data or claiming certainty from a single proxy or frame.

What it does

Radar and Satellite Analysis interprets already-decoded radar and satellite weather products as remote-sensing observations, not ground truth - validating scan time, geometry, calibration, quality flags, and coverage before interpreting any feature, then keeping what an instrument directly measures separate from what a meteorological inference suggests. It runs after a source-specific fetching skill has already retrieved and decoded the data; it does not discover buckets, download files, or repair outages.

Before interpreting any pixel or beam it records an analysis contract: the event, region, and UTC interval; the radar site/product level/elevation angles or satellite platform/product/channel/scan mode; the measurement height or viewing geometry; quality masks and missing-data policy; the allowed lag between radar, satellite, and model guidance; and the criteria for calling an interpretation confident, tentative, or inconclusive. It insists on keeping observation time, scan start/end time, file creation time, and analysis time separate - a file created quickly after a scan is not a newer measurement.

For radar it confirms site, volume time, sweep count, and moments (Level II, Level III, and real-time chunks are not interchangeable), accounts for range-dependent beam width, beam height, terrain blockage, range folding, attenuation, and velocity dealiasing, and keeps base reflectivity, VIL, echo top, and other derived products distinct rather than interchangeable. It explicitly forbids calling a reflectivity threshold hail, tornado, or destructive wind without velocity, cloud-top, lightning, surface, or model context, and treats a single velocity couplet as a candidate rotation signature rather than a confirmed tornado. For satellite it confirms platform, channel, and scan mode, applies channel-specific calibration, and treats cloud-top parallax as a viewing-geometry problem rather than a positioning error - an infrared cold cloud top alone is not proof of severe weather or a particular updraft strength.

For time sequences it uses a consistent feature-identification and tracking method across scans, distinguishes real motion from apparent motion caused by parallax or inconsistent feature definitions, and reports the tracking method, time interval, and position uncertainty rather than treating a single frame-to-frame displacement as a reliable nowcast. When combining radar and satellite, it aligns them in time and space first and preserves each source's quality mask and contribution rather than collapsing them into one opaque score - for multi-radar mosaics, it never averages dBZ or velocity across sites without a documented, quality-aware rule.

The output contract requires the site/platform/product/scan interval/region/time range, every preprocessing and calibration step taken, the observed feature with supporting pixels or beams identified, an explicit separation between direct measurement, derived index, and interpretation, stated uncertainty and alternative explanations, and figures that preserve timestamps, color scales, units, and source - rejecting a report that says only "severe storm" or "rapidly developing convection" without a location, time, measured proxy, and supporting evidence underneath the label.

When to use - and when NOT to

Use it to interpret NEXRAD reflectivity, velocity, or multi-moment volumes; track storm growth, decay, splits, mergers, or cloud-top evolution over time; analyze GOES visible, infrared, or water-vapor products; combine radar structure with satellite cloud-top evidence; produce a short-term precipitation or severe-weather nowcast from an observation sequence; or explain why a feature is or isn't supported by the data.

Do not use it to infer surface hail size, wind speed, rainfall rate, or lightning count from a single proxy without stating the retrieval assumptions, or to claim a storm's future track or intensity from a single still image.

Inputs and outputs

Input is already-retrieved, decoded radar and/or satellite products with their metadata. Output is a traceable analysis report separating direct measurement from derived index from meteorological interpretation, with stated uncertainty, alternative explanations, coverage limitations, and provenance for every derived artifact.

Integrations

Consumes data retrieved by noaa-radar-satellite-fetching or an equivalent source-specific skill; does not itself fetch data, construct mosaics, or run numerical model comparison.

Who it's for

Atmospheric scientists and severe-weather analysts interpreting radar and satellite observations who need a disciplined separation between what the instrument measured and what that measurement plausibly means - avoiding overclaiming hail, tornado, or intensification from a single proxy or frame.

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.