opencode-skills-collection 4.0.74 → 4.0.76

package/bundled-skills/mcp-dependency-drift-audit/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: mcp-dependency-drift-audit
+description: "Statically audit MCP configs for mutable npm/npx package references before approval or CI, without executing discovered MCP servers."
+category: security
+risk: safe
+source: "https://github.com/tomelias10/mcp-drift-check"
+source_repo: tomelias10/mcp-drift-check
+source_type: community
+date_added: "2026-09-25"
+author: tomelias10
+tags: [mcp, ai-security, supply-chain, devsecops, sarif]
+tools: [claude, cursor, gemini, codex, windsurf]
+license: MIT
+license_source: "https://github.com/tomelias10/mcp-drift-check/blob/v0/LICENSE"
+---
+
+# MCP Dependency Drift Audit
+
+## Overview
+
+Audit Model Context Protocol configuration files for npm/npx package references that can resolve to different code after the configuration was reviewed. The workflow is deliberately static: it reads config text, classifies version selectors, and recommends reproducibility fixes without starting discovered MCP servers.
+
+Dependency mutability is a review-boundary signal, not proof that a package is malicious, vulnerable, or compromised.
+
+## When to Use This Skill
+
+- Before approving `.mcp.json`, Cursor, VS Code, GitHub Copilot, Claude, or Windsurf MCP configuration.
+- When adding an MCP configuration gate to pull requests or CI.
+- During an AI-agent security review where npm/npx-backed MCP servers are configured.
+- When checking whether a previously reviewed MCP config can silently resolve to newer package code.
+
+## How It Works
+
+### Step 1: Locate and read MCP configs without executing them
+
+Inspect known project paths such as `.mcp.json`, `.github/mcp.json`, `.cursor/mcp.json`, `.vscode/mcp.json`, and `.windsurf/mcp.json`, plus any MCP config explicitly supplied by the user.
+
+Read them as text/JSON only. Never run a discovered `command` or `args` value as part of this audit. Stay inside the requested workspace by default; only include user-level/global MCP configuration if the user explicitly asks for machine-wide scope.
+
+### Step 2: Use MCP Drift Check when already available
+
+If `mcp-drift-check` is already installed, use the workspace-scoped mode from the intended repo root:
+
+```bash
+mcp-drift-check scan-workspace --markdown
+```
+
+For CI evidence:
+
+```bash
+mcp-drift-check scan-workspace --sarif mcp-drift.sarif --markdown
+```
+
+If the scanner is not installed, explain that the following command fetches the open-source scanner from GitHub and get user approval before running it:
+
+```bash
+uvx --from git+https://github.com/tomelias10/mcp-drift-check mcp-drift-check scan-workspace --markdown
+```
+
+If the user declines network access or installation, continue with the manual rules below.
+
+### Step 3: Apply the manual static rules
+
+For npm/npx-style package selectors:
+
+| Selector | Classification | Reason |
+| --- | --- | --- |
+| `package@1.2.3` | SAFE | Exact package version is reproducible. |
+| bare `package` or `@scope/package` | HIGH | A later resolution can select different package code. |
+| `package@latest` | HIGH | The selector is explicitly mutable. |
+| `package@^1.2.0`, `~1.2.0`, `>=1.2.0`, wildcard | MEDIUM | Resolution can change within the allowed range. |
+| local path, script, binary, unknown executable | REVIEW | npm version-drift rules do not establish update behavior. |
+
+Treat `-y` / `--yes` as context only. It suppresses interactive confirmation but is not a vulnerability by itself.
+
+### Step 4: Recommend remediation without inventing versions
+
+For mutable npm/npx references, recommend pinning to an exact version that the team has actually reviewed and then updating that pin deliberately.
+
+Do not guess the version to pin. If registry lookup is needed, explain that it requires network access and ask before querying it.
+
+Pinning improves reproducibility. It does not establish package provenance, vulnerability status, authorization safety, prompt-injection resistance, or runtime isolation.
+
+### Step 5: Produce a bounded report
+
+Return:
+
+| Config | MCP server | Package/reference | Classification | Why | Recommended next step |
+| --- | --- | --- | --- | --- | --- |
+
+Then state:
+
+- No MCP servers were executed during the audit.
+- Mutable dependency references are review/reproducibility signals, not breach claims.
+- A clean dependency-drift result is not a complete MCP security assessment.
+
+## Examples
+
+### Example 1: Audit before approval
+
+**User:** `Audit this repo's MCP config before we approve it. Do not run any MCP servers.`
+
+**Expected shape:**
+
+```text
+.mcp.json | browser | @example/browser-mcp@latest | HIGH
+Reason: @latest can resolve to different package code later.
+Next step: pin the exact version your team reviews and update it deliberately.
+
+No MCP servers were executed.
+```
+
+### Example 2: Add a CI gate
+
+For GitHub Actions:
+
+```yaml
+- uses: actions/checkout@v4
+- uses: tomelias10/mcp-drift-check@v0
+```
+
+MCP Drift Check can also emit SARIF 2.1.0 for GitHub Code Scanning. The action defaults to workspace-only discovery; machine-wide user-level scanning remains an explicit `scan-all` choice.
+
+## Best Practices
+
+- ✅ Read config text only during discovery and classification.
+- ✅ Keep the default scope to the requested workspace/repository.
+- ✅ Separate reproducibility findings from vulnerability or compromise claims.
+- ✅ Pin only a version the team has actually reviewed.
+- ✅ Keep sensitive config values out of reports and public issues.
+- ❌ Do not execute server commands found in a config to "verify" a static finding.
+- ❌ Do not treat a clean result as a general MCP security guarantee.
+
+## Limitations
+
+- This workflow only covers dependency mutability/review drift for package-backed MCP configuration.
+- It does not assess prompt injection, tool poisoning, OAuth/authorization, server implementation flaws, malware, provenance, or runtime sandboxing.
+- Local executables and non-npm launch paths require separate review.
+- A static config can be reproducible and still unsafe for other reasons.
+
+## Security & Safety Notes
+
+- The default workflow is read-only, local, and workspace-scoped.
+- Never execute discovered MCP server commands during this audit.
+- Never include credentials, tokens, private headers, or secret values in the output.
+- The optional `uvx` path makes a network fetch from the declared GitHub source; obtain user approval before running it.
+- If deeper active testing is requested, stop and establish explicit authorization and scope before any intrusive action.
+
+## Common Pitfalls
+
+- **Problem:** Calling an unpinned dependency a vulnerability.
+  **Solution:** Describe it as a reproducibility/review-drift signal unless separate evidence establishes security impact.
+- **Problem:** Pinning to today's registry version without knowing what was reviewed.
+  **Solution:** Ask for the reviewed version or, with approval, reconstruct relevant package history; do not guess.
+- **Problem:** Treating `-y` as the core finding.
+  **Solution:** Report it only as context; the version selector determines the dependency-drift classification.
+- **Problem:** Scanning user-level MCP configs when the user only asked about one repo.
+  **Solution:** Use `scan-workspace` by default; use `scan-all` only when machine-wide scope is explicit.
+
+## Related Skills
+
+- `@mcp-server-security` - Broader MCP server hardening, authentication, authorization, transport, and runtime controls.
+- `@supply-chain-security` - Broader software supply-chain assessment beyond MCP configuration.
+- `@sast-scanning` - Static application-security analysis for source code rather than MCP launch configuration.
+
+## Additional Resources
+
+- [MCP Drift Check stable v0](https://github.com/tomelias10/mcp-drift-check/tree/v0) - MIT zero-execution scanner, GitHub Action, workspace-scoped mode, and SARIF output.
+- [Public MCP dependency drift examples](https://site-creator-vinext-starter.surfaceproof.workers.dev/research/mcp-dependency-drift) - Commit-specific public configuration examples and methodology limitations.

package/bundled-skills/nexrad-mosaic-access/SKILL.md

@@ -0,0 +1,297 @@
+---
+name: nexrad-mosaic-access
+description: "Access official NOAA/NCEP MRMS radar and multisensor composites for a region and time; validate product, grid, domain, quality, timestamp, and provenance."
+category: data
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-25"
+author: ShianMike
+tags: [weather, nexrad, mrms, mosaic, qpe, vil, vii, mesh, composite-products]
+tools: [claude, cursor, gemini, codex]
+---
+
+# NEXRAD Mosaic Access
+
+## Overview
+
+Retrieve an existing NOAA/NCEP Multi-Radar/Multi-Sensor (MRMS) product without
+confusing it with a single NEXRAD volume or a locally constructed mosaic.
+MRMS provides timestamped 2D radar-only and multisensor products for regional
+analysis. Select the exact product, domain, time, and file before downloading,
+then validate the decoded grid and provenance. This skill covers access to
+existing MRMS products; it does not build a custom multi-radar composite.
+
+Use `nexrad-product-access` when the user needs one radar site's Level II or
+Level III data. Use this skill when the requested object is already a mosaic or
+multisensor analysis such as QPE, VIL, VII, or MESH.
+
+## When to Use This Skill
+
+- Access an official NEXRAD-derived national or regional mosaic.
+- Retrieve MRMS radar-derived or multisensor precipitation products.
+- Access VIL, VII, MESH, or MultiSensor QPE for a specified UTC time.
+- Obtain a completed product for mapping or analysis without downloading every
+  contributing radar volume.
+- Compare mosaic products while preserving product identity, generation time,
+  domain, and grid metadata.
+
+Do not use this skill for a single-site sweep, a Level II moment, or a custom
+mosaic that must be constructed from several radars. Route those tasks to
+`nexrad-product-access` or a dedicated mosaicking workflow.
+
+## Official MRMS 2D Access
+
+NOAA/NCEP exposes the 2D product archive at:
+
+```text
+https://mrms.ncep.noaa.gov/2D/
+```
+
+The public index includes directories such as:
+
+```text
+https://mrms.ncep.noaa.gov/2D/MultiSensor_QPE_01H_Pass1/
+https://mrms.ncep.noaa.gov/2D/VIL/
+https://mrms.ncep.noaa.gov/2D/VII/
+https://mrms.ncep.noaa.gov/2D/MESH/
+```
+
+These are representative examples, not a complete product catalog. NOAA/NSSL
+describes the MRMS suite as containing 100+ products; available products and
+distribution formats vary by product, version, domain, and feed. Consult the
+current [NOAA/NSSL MRMS overview](https://www.nssl.noaa.gov/projects/mrms/),
+product guide, and live NCEP index rather than treating this short list as an
+allowlist.
+
+Directories can contain a convenience link such as
+`MRMS_<Product>.latest.grib2.gz` and timestamped compressed GRIB2 files. Some
+products may also have regional directories such as `CONUS`, `GUAM`, or
+`CARIB`; verify the selected product directory rather than assuming a domain.
+
+For reproducible analysis, prefer an exact timestamped file. Use the `latest`
+link only for a live snapshot, then record the exact timestamp, URL, redirect
+target if any, content length, and retrieval time.
+
+## Choose the Composite Product
+
+Do not select a directory from a color image or a familiar abbreviation alone.
+Read the current product description and metadata enough to confirm:
+
+- product name and version;
+- whether it is radar-only, multisensor, gauge corrected, or analysis based;
+- accumulation or integration period;
+- valid or scan time semantics;
+- update cadence and latency;
+- spatial domain and grid;
+- missing, no-data, and quality semantics;
+- units, scale, and packed-data representation.
+
+Important distinctions include:
+
+- **QPE:** accumulated precipitation estimate, not a reflectivity image.
+- **VIL:** vertically integrated liquid from radar structure, not surface rain
+  rate or hail mass.
+- **VII:** vertically integrated ice from radar structure, not total
+  precipitation.
+- **MESH:** maximum expected size of hail for the product interval, not the
+  current cloud-top temperature or a verified hail observation.
+
+Use the current product documentation to confirm exact meaning. Do not infer a
+product from its directory name alone.
+
+## Define the Mosaic Request
+
+Record:
+
+- exact MRMS product and version;
+- national, regional, or other available domain;
+- exact valid time or bounded historical interval;
+- `latest` or timestamped-file policy;
+- variables, units, accumulation period, and quality fields;
+- desired geographic crop and output grid policy;
+- maximum lookback, file-size limit, and acceptable latency;
+- whether the product is being treated as official mosaic truth, an analysis
+  input, or a comparison target;
+- required provenance and artifact policy.
+
+If the user requests one storm's single-radar structure, this is the wrong
+skill. A mosaic is useful for broad coverage and regional products but can
+obscure site-level vertical or velocity structure.
+
+## Access Workflow
+
+1. Open or list the documented product directory under `/2D/`.
+2. Match the exact product, domain, and timestamp policy.
+3. Select an exact timestamped compressed GRIB2 file for retrospective work.
+4. For `latest`, follow the convenience link only after recording the final URL
+   and resolving its timestamped identity.
+5. Request file metadata with a bounded HTTP `HEAD` or equivalent read-only
+   check when the server supports it.
+6. Download to a request-owned temporary path without executing content from
+   the server path.
+7. Verify received size and a provider checksum when present; otherwise compute
+   and record a local SHA-256.
+8. Decompress the `.gz` into a new temporary `.grib2` file. Do not decompress in
+   place over a shared cache entry.
+9. Open the GRIB2 with a format-aware decoder and verify product, reference
+   time, forecast or valid time, grid, variables, units, and missing values.
+10. Promote the verified product and record its source identity.
+
+Keep compressed bytes, decoded values, and any reprojected or cropped artifact
+as separate stages with separate hashes or identities.
+
+## Handle Latest and Historical Time Correctly
+
+`latest` is a moving convenience name. A later request can return different
+bytes even though its URL is unchanged. For analysis and publication:
+
+- resolve `latest` to the actual timestamped file;
+- record retrieval time and product valid or scan time separately;
+- use the timestamped file for replay;
+- do not use the `latest` URL as immutable provenance;
+- report latency between product time and retrieval time.
+
+If the directory contains multiple passes, revisions, or accumulation windows,
+select the exact contract required by the task. Do not choose the newest file
+merely because its name sorts last.
+
+## Validate the Mosaic Grid
+
+Before interpreting or plotting, verify:
+
+- domain and expected geographic extent;
+- projection or GRIB coordinate definition;
+- x/y orientation and scan mode;
+- latitude and longitude coordinates after decoding;
+- cell size, dimensions, and row or column ordering;
+- time coordinate, units, and interval semantics;
+- no-data, missing, and quality values;
+- packed scale and offset or other calibration;
+- consistency with the product's documented grid contract.
+
+Do not transpose, flip, or relabel a grid based on visual appearance alone. A
+plausible-looking map can still be spatially reversed or attached to the wrong
+time.
+
+## Preserve Product and Measurement Meaning
+
+An MRMS product is a processed estimate or analysis. Keep these distinctions
+visible:
+
+- radar reflectivity or velocity input versus accumulated precipitation;
+- radar-only estimate versus gauge-corrected multisensor analysis;
+- valid time versus product generation or file publication time;
+- missing radar coverage versus a physical zero;
+- official composite product versus locally interpolated or blended fields;
+- analysis value versus uncertainty or quality metadata.
+
+Do not label an official mosaic as ground truth. It is a provider product with
+its own assumptions, coverage, latency, and quality limitations.
+
+## Reliability and Cache Behavior
+
+- Cache by product, domain, timestamped source URL, byte identity, and local
+  checksum—not by `latest` or a friendly timestamp alone.
+- Retry timeouts and transient server failures with bounded backoff and jitter.
+- Honor service limits and avoid parallel directory-wide downloads.
+- Keep partial compressed or decompressed files outside accepted cache entries.
+- Publish a complete file atomically only after decoder validation.
+- Remove request-owned temporary files after the final artifact and provenance
+  record are durable; never delete a shared user cache as request cleanup.
+
+For large regional or national products, check available disk space and memory
+before download and decode. Crop only after validating the native grid unless
+the source supports a documented range request that preserves the same bytes.
+
+## Examples
+
+For “the latest MRMS one-hour multisensor QPE over CONUS before a given UTC
+time,” verify that the product/domain exists, choose a completed timestamp,
+and record valid time separately from retrieval time. Decode the GRIB2 and
+confirm accumulation units, grid orientation, and missing-value encoding
+before mapping it.
+
+For “show the latest MRMS VIL,” resolve `latest` to its timestamped file and
+label the result as vertically integrated liquid, not surface rainfall.
+
+## Return a Mosaic Access Record
+
+```json
+{
+  "provider": "NOAA/NCEP MRMS",
+  "product": "MultiSensor_QPE_01H_Pass1",
+  "domain": "CONUS",
+  "requested_time_utc": "2026-09-25T12:00:00Z",
+  "selected_timestamped_url": "https://mrms.ncep.noaa.gov/2D/.../EXACT_FILE.grib2.gz",
+  "retrieved_at_utc": "2026-09-25T12:03:14Z",
+  "compressed_size_bytes": 12345678,
+  "compressed_sha256": "HEX_DIGEST",
+  "decoded_grid": {
+    "dimensions": [WIDTH, HEIGHT],
+    "projection": "DECODED CRS OR PRODUCT CRS",
+    "time_semantics": "VERIFIED PRODUCT TIME"
+  },
+  "latest_used": false
+}
+```
+
+Do not put a fabricated domain, grid, or time into this record. Omit unknown
+fields or use `null` when the schema permits it.
+
+## Verification Checklist
+
+- Product, version, domain, and time contract are explicit.
+- An official composite product is not confused with a single-site volume.
+- Exact timestamped identity is recorded even when access starts from `latest`.
+- Compressed bytes and decoded GRIB2 are validated separately.
+- Product, reference time, valid time, grid, units, and missing values are
+  verified after decoding.
+- Radar, multisensor, gauge-corrected, or analysis semantics are preserved.
+- Missing coverage is not converted to a physical zero.
+- The final artifact and provenance identify the exact source file.
+
+## Security & Safety Notes
+
+- Use public or authorized MRMS resources only.
+- Never execute or import content based only on a remote filename. Decode with
+  explicit format-aware libraries and bounded resource use.
+- Do not expose private endpoints, credentials, signed query strings, or tokens
+  in records or logs.
+- Validate product and domain values before constructing URLs; do not allow path
+  traversal from untrusted input.
+- Preserve NOAA/NCEP attribution and applicable data-use terms.
+
+## Common Pitfalls
+
+- **`latest` changed after the analysis:** A moving convenience link was stored
+  as immutable provenance. Resolve and retain the timestamped file identity.
+- **A missing-data region became zero:** The no-data sentinel was treated like a
+  physical value. Apply and verify the product's missing-data contract.
+- **A VIL image was called rainfall:** The processed quantity was relabeled.
+  Preserve VIL as vertically integrated liquid.
+- **A domain was assumed:** The requested regional directory may not exist for
+  that product. Inspect the actual product directory.
+- **A single radar became a mosaic:** A site product was labeled composite
+  without combining or retrieving multiple contributions.
+- **The map was flipped:** Grid orientation or scan mode was guessed from
+  appearance. Validate decoded coordinate metadata.
+
+## Limitations
+
+- Product availability, version, directory layout, and update cadence can
+  change. Verify current official documentation.
+- An official mosaic does not expose every native Level II moment or sweep.
+- Provider mosaics have their own quality, coverage, latency, and algorithmic
+  limitations and are not direct observations.
+- This skill accesses existing composites; it does not construct a custom
+  multi-radar mosaic or perform meteorological verification.
+
+## Additional Resources
+
+- [NOAA/NCEP MRMS 2D product directory](https://mrms.ncep.noaa.gov/2D/)
+- [NOAA/NSSL MRMS overview and product suite](https://www.nssl.noaa.gov/projects/mrms/)
+- [MRMS VIL example directory](https://mrms.ncep.noaa.gov/2D/VIL/)
+- [MRMS VII example directory](https://mrms.ncep.noaa.gov/2D/VII/)
+- [MRMS MultiSensor QPE example directory](https://mrms.ncep.noaa.gov/2D/MultiSensor_QPE_01H_Pass1/)
+- [NEXRAD on the AWS Registry of Open Data](https://registry.opendata.aws/noaa-nexrad/)