Add cloud-native-geo skill

[wrynearson]

This skill aims to help people using agents use cloud-native geospatial formats and tools. It gives the LLM context about our niche, cutting-edge (that the model probably wasn't trained on) world and instructions to fetch docs > relying on memory. For people who don't know (a lot) about CNG, this skill can help them use and learn about it.

Below is 🤖 Generated with Claude Code

---

What this is

A skill for choosing and using cloud-native geospatial formats and the tools that read, write, serve, and visualize them — COG, STAC, Zarr/Icechunk/GeoZarr, GeoParquet, PMTiles, FlatGeobuf, COPC, MosaicJSON — with DevSeed's stack (titiler, rio-tiler, obstore, pgstac, eoAPI, deck.gl-raster, lonboard) as the default.

Shoutout to @dzole0311 for the idea!

Why

Picking a format here depends on four things — data shape, access pattern, whether it needs a backend, and what infrastructure already exists — and the answer changes completely across them. Claude tends to commit to a stack before knowing any of them.

The libraries also move faster than training data. Several are under two years old; obstore and deck.gl-raster postdate most of it. Memorized snippets for these are wrong often enough to be worth a rule.

So: lead with the questions when the request doesn't pin down all four axes, and fetch current docs before writing code against anything on the fast-moving list.

What's in it

• SKILL.md — the two rules, a decision guide, a verify-before-coding table
• references/formats.md — per-format primers and the gotchas that bite (COG IFD ordering, WGS84 bbox reprojection for STAC, polar CRS producing NaN in fitBounds, colormap-on-multiband 500s)
• references/python-stack.md, references/visualization.md — server-side and client-side tooling

Note

.github/ (a weekly job checking 22 tracked packages against live registries; opens one issue on drift, closes it when resolved) is also included in this PR.
If it's too noisy or unnecessary, we can remove this.

Tests

Full record in skills/cloud-native-geo/evals/. 5 reps per arm per scenario, fresh subagent each, identical prompts except the skill, all arms with tools.

	Control	With skill
Led with questions instead of a recommendation	0/5	5/5
Doc fetches before writing code	0,0,0,0,0	7,8,6,6,8
Reported the undocumented obstore/rio-tiler pairing	0/5	5/5
Distinct APIs produced for one prompt	5 (all different)	1 (converged)

Both failure modes reproduced cleanly. Asked how to show a Sentinel-2 scene from S3 on a web map, every control run recommended a stack before knowing whether the file was a COG, and three proposed re-hosting data that was already in the user's own bucket. Asked for an obstore + rio-tiler snippet, every control run wrote code with zero lookups and produced five incompatible APIs — including a module that doesn't exist and a class renamed back at 4.0 — at 75–95% stated confidence.

The first pass scored 4/5 and 3/5 on the first two rows. Rewriting the rules as output contracts rather than advice took both to 5/5. A third edit — split verified from inferred instead of one blended confidence number — reached only 2/5 and is left as an open item.

Caveats, all recorded: runs were on Haiku; the control arm inherited repo context and skewed toward titiler, making the gap conservative; the skill was inlined rather than loaded normally, so description-driven selection is untested; n=5.

[claude]

Claude finished @wrynearson's task in 2m 7s —— View job

---

✅ No blocking issues — safe to merge.

Mostly documentation (SKILL.md + references), which reads clearly and is well-scoped. The only real code is the freshness-check automation (.github/scripts/check_cloud_native_geo_freshness.py + workflow + manifest), which is careful about things that usually go wrong in scripts like this: no pull_request trigger (so no untrusted-code-with-write-token risk), scoped-down workflow permissions, gh invoked with argument lists (no shell injection), request timeouts, and per-package exception isolation so one bad fetch doesn't kill the run.

One non-blocking correctness note worth a follow-up:

• .github/scripts/check_cloud_native_geo_freshness.py:78-92 (check_entry) returns None both when a package hasn't drifted and when the fetch failed (network error, unexpected registry shape, etc.). main() (line 187-192) treats an all-None result as "everything matches" and closes any open tracking issue. So a transient failure across all/most fetches (registry hiccup, GitHub API rate-limit) would cause the job to silently close a legitimately-open drift issue instead of reporting "couldn't verify." Low blast radius (a real drift would just reopen the issue on the next successful weekly run), but worth distinguishing "no drift" from "couldn't check" — e.g. collect failures separately and skip sync_issue(None) if any occurred.

  failures = []
  drifted = []
  for entry in manifest:
      result = check_entry(entry)  # have check_entry raise or return a sentinel on fetch failure
      ...
  if failures and not drifted:
      print(f"{len(failures)} package(s) could not be checked; leaving any existing issue as-is.")
      return 1

Everything else checked out:

• URLs/registry lookups (PyPI, npm incl. scoped @developmentseed/deck.gl-raster, GitHub releases/tags) are constructed correctly.
• find_open_issue intentionally avoids gh issue list --search due to GitHub's search-index lag — reasoning is documented in the docstring, not a bug.
• marketplace.json / skills/cloud-native-geo/.claude-plugin/plugin.json follow the existing convention used by the other skills (no license field there either — consistent).
• No secrets, no new third-party dependencies beyond pyyaml (already minimal — stdlib urllib used instead of adding requests).

Simplify (ponytail): nothing to cut — the freshness-check script solves a problem stdlib/existing tooling doesn't (diffing a curated package list against three different registries and syncing a single tracking issue), uses stdlib urllib over adding requests, and skips semver comparison it doesn't need (plain string inequality is enough to detect drift). No speculative abstractions, no unused config surface.

---

💰 Estimated review cost: $0.52 · 2m06s · 26 turns