opencode-skills-collection 4.0.74 → 4.0.76

package/bundled-skills/nexrad-radar-visualization/SKILL.md

@@ -0,0 +1,318 @@
+---
+name: nexrad-radar-visualization
+description: "Plot NEXRAD Level II/III site scans and decoded radar mosaics with correct radar geometry, map grids, units, quality masks, timestamps, and provenance."
+category: analysis
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-25"
+author: ShianMike
+tags: [weather, nexrad, radar-plotting, ppi, velocity, dual-pol, cross-section, visualization]
+tools: [claude, cursor, gemini, codex]
+---
+
+# NEXRAD Radar Visualization
+
+## Overview
+
+Create scientifically legible plots from verified NEXRAD single-site products
+and decoded radar mosaics. Preserve site or domain, product, observation or
+valid time, units, geometry, quality masking, and color meaning so a visually
+compelling image cannot hide a wrong quantity or misleading spatial
+interpretation.
+
+Use this skill after `nexrad-product-access` or another trusted source has
+provided a decoded site product. Use `nexrad-mosaic-access` to retrieve an
+official MRMS composite before plotting it. This skill does not discover or
+download radar files.
+
+## When to Use This Skill
+
+- Plot base reflectivity, radial velocity, spectrum width, or another decoded
+  Level II moment for one NEXRAD site.
+- Plot a Level III product selected by product code and scan time.
+- Plot a decoded NOAA/NCEP MRMS or other documented NEXRAD-derived gridded
+  composite while preserving its grid, coverage, and product semantics.
+- Create a lowest-elevation PPI, a specified-elevation PPI, or a sweep chosen
+  for a target height.
+- Plot dual-polarization moments with appropriate units and masks.
+- Create RHI, cross-section, tilt, storm-relative, or multi-sweep views.
+- Build a time sequence or animation from a verified scan series.
+- Export the plot with a stable color scale, map context, metadata, and
+  provenance.
+
+Do not use a plot to hide a missing sweep, unverified product, invalid gate mask,
+geolocation error, or unsupported extrapolation.
+
+## Define the Visualization Contract
+
+Record:
+
+- radar site and site coordinates;
+- data level and exact product or moment;
+- observation, volume, or product time in UTC;
+- source identity and local content hash when required;
+- intended view: PPI, RHI, cross-section, tilt, comparison, or animation;
+- sweep or angle policy;
+- map projection, bounds, range rings, and landmark context;
+- physical units, color scale, display range, and normalization policy;
+- invalid, missing, folded, clutter, or otherwise masked gates;
+- for gridded mosaics, the provider, product/domain, grid projection and
+  orientation, valid-time semantics, and source/coverage or quality fields;
+- output format, dimensions, background, and whether figures are for analysis or
+  publication.
+
+If the user asks only for “a radar image,” produce a useful default: a
+single-site PPI with site marker, UTC time, product, units, color bar, range
+rings, and missing-data treatment visible. For a decoded mosaic, use a map view
+with the product, domain, valid time, units, legend, and missing-data treatment
+visible. Ask only when product, site/domain, or time would materially change
+the result and cannot be inferred safely.
+
+## Validate Before Plotting
+
+1. Confirm the decoded site, product or moment, time, units, dimensions, and
+   projection.
+2. Apply scale, offset, calibration, fill values, and quality flags before
+   interpolation, contouring, or thresholding.
+3. Confirm that the requested sweep exists. For a target-height sweep, compute
+   or obtain beam height as a function of range and show which elevation is
+   nearest.
+4. Preserve no-data and invalid-data cells as masked values. Do not replace them
+   with zero, minimum reflectivity, or an opaque background that resembles weak
+   echo.
+5. Confirm that map coordinates and radar polar coordinates share the correct
+   projection and origin.
+6. Record whether velocity is dealiased and whether dual-polarization fields have
+   their documented quality masks.
+
+## Plot a PPI
+
+For a plan-position indicator:
+
+1. Select the requested sweep or the lowest usable sweep under a stated policy.
+2. Convert range and azimuth to the selected map projection.
+3. Mask invalid, below-threshold display, folded, clutter-contaminated, and
+   missing gates according to an explicit policy.
+4. Render the measured product with a documented, perceptually ordered color
+   scale appropriate to the quantity.
+5. Overlay radar location, requested site label, range rings or distance scale,
+   north arrow when orientation could be ambiguous, and optional geographic
+   context.
+6. Put product, site, UTC time, units, sweep or product code, range, and color bar
+   in the figure itself.
+
+For reflectivity, do not imply that every dBZ color boundary is a categorical
+precipitation type. Keep the measured reflectivity label visible and put any
+rain-rate relation in a separate, explicitly derived layer.
+
+For velocity, use a diverging scale centered on zero unless the product's
+documented semantics require another convention. Radial velocity points toward
+or away from the radar according to the data convention; it is not a full wind
+vector. Do not draw environmental wind arrows from radial velocity without an
+explicit deconvolution or retrieval method.
+
+## Plot Dual-Polarization Moments
+
+Preserve the physical unit for each field, such as differential reflectivity in
+dB, differential phase in degrees, correlation coefficient as a unitless
+quantity, and specific differential phase with its documented units and scale.
+
+Keep raw dual-polarization fields separate from hydrometeor classification. If a
+classification is displayed, state the input moments, thresholds, quality
+masking, and whether the classification is measured, retrieved, or heuristic.
+
+Do not normalize each sweep independently before an animation or comparison;
+that can make a changing storm look stationary. Use one declared scale for the
+whole sequence unless a separate panel is explicitly labeled.
+
+## Choose a Sweep for a Target
+
+Lowest-level products emphasize near-surface structure but are vulnerable to
+terrain, clutter, biological targets, and beam broadening. Higher sweeps sample
+different heights and can miss low-level features.
+
+When selecting a sweep by target height:
+
+1. use the radar elevation angles and a documented beam-height relationship;
+2. solve for the nearest sweep at the requested range and height;
+3. label the selected elevation and estimated sampling height;
+4. show the choice on a vertical cross-section when the selection is material.
+
+Do not call the lowest sweep a surface observation. Its beam samples a volume
+whose center height varies with range and whose width increases away from the
+radar.
+
+## Plot RHI, Cross-Sections, and Tilts
+
+An RHI or cross-section is a derived view assembled from multiple sweeps or
+volumes. Preserve source volume identity, azimuth or line orientation,
+horizontal-distance coordinate, vertical coordinate, interpolation method, and
+beam-height geometry.
+
+Do not connect gates across large angular gaps, missing sweeps, or incompatible
+volumes without showing the gap. Avoid implying sub-beam vertical resolution.
+For a storm tilt sequence, use the same cross-section line or documented tracking
+logic across times and show how the line moves.
+
+## Create Time Sequences
+
+For an animation or loop:
+
+- use a verified chronological scan sequence;
+- preserve the requested cadence and mark skipped or duplicated scans;
+- keep site, product, color scale, map bounds, and range constant;
+- show UTC time on every frame or in a clearly visible persistent timestamp;
+- do not duplicate a stale frame to fill a gap without labeling the hold;
+- stop at the last verified frame when the stream ends.
+
+An animation is not evidence of temporal evolution unless frames are aligned,
+correctly timed, and generated from the same product and projection.
+
+## Plot a Precomputed Mosaic
+
+For an MRMS or other decoded NEXRAD-derived grid:
+
+1. Verify product identity, domain, valid or accumulation time, units, grid
+   projection, dimensions, coordinate orientation, and decoded extent.
+2. Apply the product's scale, offset, fill values, quality flags, and coverage
+   mask before rendering. Preserve missing coverage as missing; do not turn it
+   into zero-valued precipitation or reflectivity.
+3. Render the documented geographic extent and coordinate grid. Reproject only
+   with an explicit transformation and retain the native grid metadata.
+4. Label the exact product, provider, domain, valid-time interval, units, and
+   color scale. Show coverage or source attribution when supplied with the
+   decoded data.
+5. Keep official provider products distinct from locally constructed mosaics;
+   use `nexrad-mosaic-construction` for construction and label its output as a
+   local analysis.
+
+Do not apply single-radar azimuth/range geometry or sweep labels to an MRMS
+grid. Do not claim a mosaic represents every native radar moment or elevation.
+
+## Design the Figure
+
+Use the minimum visual elements needed to interpret the measurement:
+
+- product and unit;
+- site or mosaic domain and UTC/valid time;
+- sweep, angle, or product code;
+- color bar with fixed limits and an explicit missing-data color;
+- radar location and range context for site plots, or geographic extent and
+  orientation for gridded plots;
+- relevant masks or quality annotation;
+- source and processing note when the figure leaves the controlled environment.
+
+Avoid decorative terrain or boundaries that obscure gates, imply high
+resolution, or dominate the measured field. Do not crop away the radar site,
+range rings, or color bar without replacing the lost context.
+
+For a multi-panel figure, label each panel by product and time and state whether
+the panels share a scale. Use consistent geometry across panels so a viewer can
+compare evolution without reorienting the scene.
+
+## Examples
+
+Given a decoded KTLX volume, render the lowest usable reflectivity sweep with
+the site, Level II moment, observed UTC time, dBZ units, color bar, range rings,
+and invalid gates visibly masked. Read the timestamp and product metadata from
+the volume rather than inventing them.
+
+When comparing two velocity scans, first verify they are from the same site,
+product, units, and sweep policy. Use one shared diverging color scale, show
+each scan's actual UTC time, and leave missing gates masked rather than filling
+them with zero velocity.
+
+When plotting an MRMS composite, retrieve the exact product and timestamp with
+`nexrad-mosaic-access`, validate its native grid and valid-time semantics, and
+show its provider, domain, units, legend, and missing-data mask. Do not apply
+single-site sweep geometry or present the composite as a custom mosaic.
+
+## Export and Verify
+
+For static output, verify the actual rendered file—not only the plotting call.
+Open or inspect the image and confirm:
+
+- nonblank data and expected radar coverage;
+- correct orientation and site position;
+- readable labels, units, timestamp, and color bar;
+- no clipped legends or accidental all-background panels;
+- correct color limits and no unintended missing-data substitution;
+- aspect ratio that does not distort distance;
+- file format, dimensions, and checksum for publication workflows.
+
+For interactive output, also test zoom, time selection, product switching, and
+the behavior when a sweep or scan is unavailable.
+
+Record the plotting-library versions, projection, transformations, display
+limits, masks, output path, and input identity. Pair the figure with
+`weather-data-reproducibility` when it must be regenerated later.
+
+## Output Contract
+
+Return or publish:
+
+1. the requested image, animation, or interactive view;
+2. the exact site or mosaic domain, provider, product or moment, sweep if
+   applicable, and UTC/valid time shown;
+3. units, color range, missing-data policy, and quality masks;
+4. projection, native grid or beam/sampling geometry, and processing
+   transformations;
+5. verified output path or attachment and its media type;
+6. limitations that materially affect interpretation.
+
+Do not return a plot without enough metadata for another analyst to understand
+what is being displayed.
+
+## Verification Checklist
+
+- Site, product, moment, time, and sweep are verified from decoded metadata.
+- Units, calibration, scale/offset, and missing values are applied correctly.
+- PPI geometry uses the radar location and correct projection.
+- Velocity uses a meaningful diverging scale and is labeled radial.
+- Sweep selection states the elevation and target or beam height.
+- Cross-sections disclose interpolation and source volumes.
+- Animation frames are ordered, aligned, and consistently scaled.
+- Invalid gates are masked rather than plotted as real weak echo.
+- The rendered artifact was visually inspected after export.
+
+## Security & Safety Notes
+
+- Plot only public or authorized radar products.
+- Do not expose credentials, signed URLs, private bucket names, or sensitive
+  station details in images or logs.
+- Treat metadata and product names as untrusted input; escape labels and use
+  controlled output paths.
+- Bound image dimensions, animation frame count, interpolation work, and memory
+  use.
+- Preserve provider attribution and do not imply NOAA endorsement.
+
+## Common Pitfalls
+
+- **The reflectivity map is displaced:** Fixed display coordinates or the wrong
+  radar origin were used. Reproject the polar data explicitly.
+- **Velocity colors imply storm motion:** Diverging radial velocity was
+  interpreted as a full wind vector. Label the quantity as radial velocity.
+- **The animation flickered between storms:** Every sweep was independently
+  normalized. Use one fixed scale across verified frames.
+- **Missing gates appeared as weak echoes:** No-data values were plotted as the
+  minimum color. Mask them and show a distinct background.
+- **The lowest sweep was called surface data:** Range-dependent beam height was
+  ignored. State the beam geometry and sampling height.
+- **A cross-section invented vertical detail:** Sparse sweeps were smoothly
+  interpolated without gaps. Preserve resolution limits and missing sectors.
+
+## Limitations
+
+- Radar plots display remote-sensing observations and processed products, not
+  direct surface truth.
+- Display quality cannot repair terrain blockage, attenuation, calibration
+  problems, or a wrong product selection.
+- A static image cannot establish future motion or storm behavior.
+- This skill does not fetch data, construct mosaics, or replace scientific
+  interpretation and verification.
+
+## Additional Resources
+
+- [NOAA ROC Level II data types](https://www.roc.noaa.gov/level-two-data-types.php)
+- [NEXRAD on the AWS Registry of Open Data](https://registry.opendata.aws/noaa-nexrad/)

package/bundled-skills/radar-satellite-analysis/SKILL.md

@@ -0,0 +1,314 @@
+---
+name: radar-satellite-analysis
+description: "Interpret weather radar and satellite observations by validating product metadata and geometry, deriving storm and cloud structures, tracking evolution, and quantifying uncertainty."
+category: analysis
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-25"
+author: ShianMike
+tags: [weather, radar, satellite, nexrad, goes, nowcasting, storm-analysis, remote-sensing, uncertainty]
+tools: [claude, cursor, gemini, codex]
+---
+
+# Radar and Satellite Analysis
+
+## Overview
+
+Analyze radar and satellite weather products as remote-sensing observations,
+not as ground truth. Validate scan time, geometry, calibration, quality flags,
+and coverage before interpreting a feature. Then separate what the instrument
+directly measures from what a meteorological inference suggests.
+
+This skill consumes already retrieved and decoded products. Use it after
+`noaa-radar-satellite-fetching` or an equivalent source-specific skill. It does
+not discover buckets, download files, repair outages, or make a product
+scientifically suitable by naming it radar or satellite data.
+
+## When to Use This Skill
+
+- Interpret NEXRAD reflectivity, velocity, spectrum width, or multi-moment
+  volumes.
+- Track storm growth, decay, splits, mergers, rotation, anvils, or cloud-top
+  evolution over time.
+- Analyze GOES visible, infrared, water-vapor, or derived cloud and convection
+  products.
+- Combine radar structure with satellite cloud-top evidence while preserving
+  each sensor's limitations.
+- Produce a short-term precipitation or severe-weather nowcast from a sequence
+  of observations.
+- Explain why a radar or satellite feature is—or is not—supported by the data.
+
+Do not infer a surface hail size, wind speed, rainfall rate, or lightning count
+from a single proxy without stating the retrieval assumptions. Do not use a
+single still image to claim a storm's future track or intensity.
+
+## Define the Remote-Sensing Analysis Contract
+
+Before interpreting pixels, beams, or profiles, record:
+
+- event, target phenomenon, region, and UTC interval;
+- radar site, product level, scan/volume interval, elevation angles, moments,
+  and resolution—or satellite platform, product, sector, channel, scan mode,
+  and resolution;
+- the measurement height or viewing geometry;
+- the quality masks, calibration or scaling, and missing-data policy;
+- the temporal cadence and the allowed lag between radar, satellite,
+  observations, and model guidance;
+- the feature definition and the expected output: structure, motion,
+  intensity proxy, nowcast, or uncertainty map;
+- the criteria for a confident, tentative, or inconclusive interpretation.
+
+Keep observation time, scan start/end time, file creation time, retrieval time,
+and analysis time separate. A file created quickly after a scan is not a newer
+measurement.
+
+## Validate the Products Before Interpretation
+
+### Common checks
+
+1. Confirm the radar site or physical satellite, product identity, sector,
+   channel or moment, and expected dimensions from the decoded metadata.
+2. Verify the time interval, scan start and end, coordinate reference system,
+   and geolocation. For GOES fixed grids, use the product's geostationary
+   projection metadata rather than treating scan `x` and `y` as latitude and
+   longitude.
+3. Apply the product's documented scale, offset, fill values, calibration, and
+   quality flags before computing statistics or thresholds.
+4. Inspect missing scans, partial volumes, data gaps, saturated or invalid
+   values, and spatial coverage. Do not smooth over a gap without labeling it.
+5. Record the resolution, footprint, and observation uncertainty. A high pixel
+   count is not a high spatial resolution if the beam or channel is coarse.
+
+### Radar-specific checks
+
+- Confirm site, volume start/end time, sweep count, moments, and elevation
+  angles. Level II, Level III, and real-time chunk products are not
+  interchangeable encodings.
+- Account for range-dependent beam width, beam height above the radar, terrain
+  blockage, range folding, attenuation, clutter, anomalous propagation, and
+  velocity dealiasing where relevant.
+- Determine whether a feature is sampled by one low-level sweep, several
+  elevation angles, or a full vertical column. Do not compare a low-level echo
+  top with a satellite cloud top as if they were the same physical surface.
+- Keep base reflectivity, column-integrated liquid, echo top, and derived
+  products distinct. Their thresholds and physical meanings are not
+  interchangeable.
+
+### Satellite-specific checks
+
+- Confirm platform, instrument, product short name, channel or RGB product,
+  sector, scan mode, and scan interval from file attributes.
+- Apply channel-specific calibration and quality flags. Brightness
+  temperature, reflectance, cloud-top temperature, and land-surface
+  temperature are different quantities.
+- Treat cloud-top parallax as a viewing-geometry problem. A high cloud can be
+  displaced from its surface footprint, especially near the edge of a sector.
+- Distinguish visible, infrared, water-vapor, and derived RGB products. Their
+  interpretation depends on reflectance, emission, atmospheric absorption, and
+  daylight or scan mode.
+
+## Analyze Radar Structure
+
+### Reflectivity and precipitation proxies
+
+Use reflectivity to describe the location and organization of precipitation
+echoes, then qualify the interpretation with beam height, range, attenuation,
+and sampling. Look for features such as:
+
+- high-reflectivity cores and their relationship to weaker surrounding echo;
+- echo overhangs, weak-echo regions, bounded weak-echo regions, and vertical
+  development;
+- bow, hook, line, multicell, or training structures when the geometry supports
+  that description;
+- echo-top or vertically integrated liquid patterns that are relevant to the
+  stated question.
+
+Do not call a reflectivity threshold hail, tornado, or destructive wind. Those
+are conditional interpretations requiring velocity, cloud-top, lightning,
+surface, or model context. Convert reflectivity to rain rate only with an
+explicit relation, sample assumptions, and uncertainty bounds; a reflectivity
+lookup is not a universal precipitation truth.
+
+### Velocity and rotation
+
+Analyze radial velocity as a radar-relative measurement. State whether the
+field is gate-to-gate shear, environmental shear, storm-relative radial flow, or
+a derived couplet. Consider dealiasing, range folding, noise, side lobes,
+velocity folding artifacts, and the fact that a velocity signature can have
+multiple meteorological explanations.
+
+For rotation or mesocyclone interpretation, use the appropriate temporal,
+azimuthal, and vertical support and compare the result with neighboring scans.
+A single couplet is a candidate feature, not a confirmed tornado. Do not use
+radial velocity as a direct measurement of the environmental wind vector
+without accounting for viewing geometry.
+
+### Three-dimensional organization
+
+When a volume supports it, align elevation angles and analyze vertical
+structure: low-level inflow, mid-level rotation, updraft organization, echo
+top, overhang, and bounded weak-echo regions. Account for increasing beam
+volume and decreasing resolution with height. A feature that appears vertically
+stacked may be a sampling or attenuation artifact; check adjacent sites or
+scans before asserting a continuous structure.
+
+## Analyze Satellite Cloud and Storm Structure
+
+Use satellite data to describe cloud-top and environmental context, not to
+replace radar precipitation structure. Depending on the product, examine:
+
+- cloud-top temperature, brightness-temperature gradients, and overshooting
+  top candidates;
+- anvil extent, spreading direction, and relationship to upper-level outflow;
+- deep-convective cloud shields and mesoscale convective systems;
+- visible-texture changes, cloud-top lowering or warming, and inferred growth or
+  decay only with a time sequence;
+- water-vapor patterns, upper-level moisture, and potential convective
+  environments when the product and resolution support those claims.
+
+An infrared cold cloud top is not, by itself, proof of severe weather, hail,
+or a particular updraft strength. A very cold top can reflect a high cloud
+whose emission and viewing geometry differ from a nearby lower cloud. State the
+proxy, the threshold, and the alternative explanation.
+
+## Track Evolution and Motion
+
+For a time sequence, use a consistent feature-identification and tracking
+method. Track cell or cloud-system centers, echoes or anvils, growth and decay,
+merges and splits, and changes in shape or intensity proxy. Distinguish motion
+from the steering flow and from apparent motion caused by parallax, changing
+scan geometry, or inconsistent feature definitions.
+
+Estimate motion over multiple scans and report the method, time interval,
+position uncertainty, and whether the feature was occluded or lost. A single
+displacement between scans is not a reliable nowcast. If a forecast window is
+short, say so and show the persistence or extrapolation assumption.
+
+## Combine Radar and Satellite Carefully
+
+Align the products in time and space before joining them. Radar can provide
+precipitation structure, radial motion, and vertical echoes; satellite can
+provide broad cloud shield, cloud-top context, anvils, and environmental
+patterns. Their footprints, resolution, viewing geometry, and quality are not
+identical.
+
+Use a joint interpretation only when the evidence is complementary. For
+example, a radar core beneath a rapidly developing cold cloud top can support a
+convective-growth diagnosis, but it still does not establish surface hail or a
+confirmed tornado. Preserve each source's quality mask and contribution in the
+final result instead of collapsing them into an opaque score.
+
+For multi-radar mosaics, resolve overlapping beams using a documented rule.
+Never average dBZ values or velocity fields across sites without a physical and
+quality-aware rule. A mosaic should show coverage and the selected source for
+each pixel or cell.
+
+## Quantify Uncertainty and Avoid Overclaiming
+
+Remote-sensing interpretation has several uncertainty sources: beam geometry,
+attenuation, parallax, threshold choice, temporal resolution, feature tracking,
+instrument calibration, cloud microphysics, and incomplete coverage. When the
+task is operational or safety-relevant, report the strongest alternative
+interpretation and the observations that would distinguish it.
+
+Use a bounded nowcast horizon and show how the result changes with alternate
+motion, persistence, growth, or decay assumptions. Do not turn a qualitative
+feature label into a precise probability without a calibration method. If the
+images are too sparse, ambiguous, or poorly geolocated, report that the
+feature is unconfirmed rather than filling the gap with narrative certainty.
+
+## Examples
+
+When asked whether a storm intensified over an hour, align successive radar
+volumes and satellite scans, verify time and geolocation, and track one
+consistent feature definition. Report measured reflectivity and cloud-top
+changes separately from inferred intensification, include data gaps and
+uncertainty, and do not infer surface hail from a cold cloud top alone.
+
+For a suspected velocity couplet, inspect neighboring scans and available
+elevation angles, confirm radial-velocity convention and dealiasing quality,
+and call it a possible rotation signature unless the evidence supports a
+stronger conclusion.
+
+## Output Contract
+
+Return a traceable analysis with:
+
+1. the radar site or satellite platform, product, channel/moment, scan interval,
+   region, and time range;
+2. the preprocessing, calibration, geolocation, quality masking, and temporal
+   alignment steps;
+3. the observed feature locations, structure, motion, and evolution with the
+   supporting pixels or beams identified;
+4. a clear separation between direct measurements, derived indices, and
+   meteorological interpretation;
+5. uncertainty, alternative explanations, and coverage limitations;
+6. figures or maps that preserve timestamps, color scales, units, and source;
+7. provenance for the raw or materialized products and every derived artifact.
+
+Avoid a report that says only "severe storm," "heavy rain," or "rapidly
+developing convection" without a location, time, measured proxy, and evidence
+beneath the label.
+
+## Verification Checklist
+
+- Radar site or satellite platform and product metadata are confirmed.
+- Scan start/end time, retrieval time, and analysis time are distinct.
+- Geolocation, projection, scale/offset, calibration, and quality flags are
+  applied.
+- Beam height, beam width, range, terrain, attenuation, and radar artifacts are
+  considered where relevant.
+- Satellite channel meaning, scan mode, daylight dependence, and parallax are
+  considered.
+- Radar and satellite claims remain separate unless their alignment and
+  complementary evidence are explicit.
+- Feature tracking uses multiple scans and reports its motion assumptions.
+- Derived products include units, thresholds, coverage, and uncertainty.
+
+## Security & Safety Notes
+
+- Use only public or authorized radar and satellite products.
+- Do not expose AWS credentials, signed URLs, private bucket names, tokens, or
+  restricted provider metadata in reports or logs.
+- Treat filenames, metadata, and product attributes as untrusted input; validate
+  them before constructing paths or visualizations.
+- Bound scan counts, image sizes, decoding concurrency, and generated artifact
+  resolution.
+- Preserve NOAA, NEXRAD, GOES, and other provider attribution and license terms.
+
+## Common Pitfalls
+
+- **The file creation time was used as measurement time:** A delayed or
+  reprocessed product was placed at the wrong point in a storm timeline. Parse
+  scan start and end time.
+- **A cold cloud top became a hail claim:** An infrared proxy was treated as a
+  direct hail measurement. State the proxy and supporting evidence.
+- **Radar and satellite features did not line up:** Scan intervals, parallax,
+  geolocation, or beam height were ignored. Align the observations first.
+- **A reflectivity pixel became a rain rate:** A threshold or lookup relation
+  was used without its assumptions and uncertainty. Keep the measured quantity
+  separate from the estimate.
+- **A storm “rapidly intensified” from two frames:** A gap, feature mismatch, or
+  inconsistent threshold was mistaken for growth. Use a longer sequence and
+  tracking evidence.
+- **Radar mosaics hid artifacts:** Values were averaged across sites or a blocked
+  beam was treated as a complete field. Retain quality and source information.
+
+## Limitations
+
+- Radar and satellite products are remote-sensing observations with sampling,
+  calibration, attenuation, parallax, and coverage limitations.
+- A single product cannot uniquely identify every convective or microphysical
+  process.
+- Historical gaps, instrument outages, scan strategy changes, and provider
+  product changes cannot be repaired by interpretation alone.
+- This skill does not retrieve products, perform numerical model comparison, or
+  replace official warning and emergency-management guidance.
+
+## Additional Resources
+
+- [NOAA Radar Operations Center interface documents](https://www.roc.noaa.gov/wsr88d/BuildInfo/Files.aspx)
+- [NOAA NEXRAD on the AWS Registry of Open Data](https://registry.opendata.aws/noaa-nexrad/)
+- [NOAA GOES on the AWS Registry of Open Data](https://registry.opendata.aws/noaa-goes/)
+- [NOAA GOES-R documents](https://www.ospo.noaa.gov/resources/documents/goes-r.html)