GeoAI Skills

Turn your AI agent into a senior geospatial data scientist.

18 Agent Skills covering the full geospatial data science lifecycle — from STAC search and PostGIS to kriging uncertainty, U-Net inference, and guarded ArcGIS Pro automation — designed around documented silent failure modes in spatial computing.

Why this exists

Spatial bugs are silent. A buffer computed in degrees still returns numbers. A random train/test split on spatial data still produces a beautiful learning curve — a fraudulent one. An unprojected choropleth still renders. Web Mercator still shows Greenland bigger than Africa.

General-purpose LLMs know the APIs but routinely commit every one of these errors, because nothing in the output looks wrong.

These skills encode the discipline that separates a practitioner from an API caller:

• CRS is explicit, always — never compute area/distance in a geographic CRS
• Spatial leakage is the default enemy — every ML-adjacent skill enforces spatial blocking
• Every stage ends with a verification check — visual + numeric, row-count accounting, error maps
• Uncertainty is a deliverable — kriging SD rasters, sensitivity analyses, error-adjusted area estimates with CIs, FDR-corrected cluster maps

What's inside

                       ┌─────────────────────┐
                       │  geoai-orchestrator │  ← entry point, pipeline design,
                       └──────────┬──────────┘    module-wide invariants
        ┌──────────┬─────────────┼─────────────┬───────────────┐
    ACQUIRE      SENSE         MODEL         ANALYZE         DELIVER
        │           │             │             │               │
  geo-data-    remote-       geo-deep-     spatial-        cartography-
  engineering  sensing-      learning      statistics      geoviz
        │      analysis          │             │
  postgis-         │        change-       geostatistics-
  spatial-sql      │        detection     interpolation
        │      google-           │             │
  point-cloud- earth-       terrain-      mcda-suitability-
  lidar        engine       hydrology     analysis
        │                        │             │
        └── movement-trajectory ─┴── network-accessibility-analysis

  cross-cutting: ml-experiment-standards · swe-devops-standards
  proprietary execution: arcgis-pro-automation (guarded local ArcPy)

Installation

Claude Code / Cowork (as a plugin):

/plugin marketplace add muend/geoai-skills
/plugin install geoai@geoai-skills

Claude.ai / Claude desktop: upload any skill folder (or zip it as .skill) via Settings → Capabilities → Skills. Skills install independently — install all 18 for full routing, or cherry-pick. Real arcgis-pro-automation execution additionally requires Windows, licensed ArcGIS Pro, and a configured local arcgis-mcp-bridge.

Any Agent-Skills-compatible runtime: copy folders from skills/ into your agent's skills directory. Each skill is self-contained; cross-references degrade gracefully when a referenced skill is absent.

Installation profiles and dependencies

• Full suite (recommended): install all skills so the orchestrator and cross-cutting verification standards are available together.
• Core profile: install geoai-orchestrator, ml-experiment-standards, and swe-devops-standards alongside any specialist skills used in multi-stage work.
• Cherry-picked skill: it must remain safe and useful by itself. Sibling skill references are advisory; critical safety rules require a local fallback. CI will progressively enforce this contract.

The open Agent Skills specification does not currently provide a portable dependency resolver. Installation documentation must therefore state required profiles explicitly rather than assuming sibling skills are present.

Usage

You don't invoke these skills — they trigger on your task. Just ask naturally:

"I have parcel shapefiles and Sentinel-2 imagery for a region. Build a land suitability model for solar farms."

The orchestrator decomposes this into a pipeline (data engineering → remote sensing → terrain → MCDA → cartography), routes each stage to the specialist skill, and enforces the invariants at every step — you'll get CRS reports, row-count accounting, a consistency-checked AHP, a sensitivity analysis, and a colorblind-safe map, without asking for any of them.

Other things that just work:

• "Detect urban growth between these two years" → co-registration checks, defensible thresholding, error-adjusted area estimates with confidence intervals
• "Interpolate these rainfall stations" → variogram discipline, kriging with an uncertainty raster, spatially honest cross-validation
• "Train a U-Net to extract buildings" → spatially blocked splits, imbalance-aware losses, georeferencing-preserving inference
• "Why is this spatial join so slow?" → EXPLAIN-driven PostGIS playbook, ST_Subdivide, index-sargable predicates

Design principles

1. Fail-loud spatial computing. Every skill mandates accounting reports, verification protocols, and visual + numeric double checks.
2. Methodological honesty. Permutation inference, FDR correction, sensitivity analysis, uncertainty rasters, and error-adjusted area estimates are deliverables, not extras.
3. Anti-leakage by default. Spatial autocorrelation makes random splits fraudulent; one canonical spatial CV protocol, referenced everywhere, restated nowhere.
4. Tool-pragmatic. Open Python stack first (GeoPandas, rasterio, xarray, PySAL, PDAL, OSMnx, WhiteboxTools), with routes to PostGIS/DuckDB at scale, Earth Engine for planetary archives, and headless arcpy/PyQGIS for proprietary environments.
5. Progressive disclosure. Descriptions are tuned for reliable triggering; bodies stay lean; long material lives in references/ and scripts/ at zero token cost until needed.
6. Measured, not assumed. The current source suite contains 131 typed scenarios across 18 skills: 91 positive, 40 negative, 30 ambiguous, 46 collision, and 38 artifact-correctness candidates (types may overlap). The published 100% precision, 92.86% recall, and 92.5% route accuracy remains tied to its frozen 17-skill, 120-case Claude Code 2.1.214 / Claude Sonnet 5 suite and disabled-skills control. arcgis-pro-automation is not included in that headline until a new exact enabled/disabled pair is published. Behavior quality remains explicitly unevaluated until an independent-family judge and manual review are complete.

Repository structure

geoai-skills/
├── skills/<skill-name>/
│   ├── SKILL.md            # the skill (agent-facing)
│   ├── scripts/            # runnable code, loaded on demand
│   ├── references/         # deep material, loaded on demand
│   └── evals/evals.json    # ≥7 typed routing + behavior scenarios
├── tools/validate_skills.py  # spec linter (runs in CI)
├── tools/validate_evals.py   # strict, versioned eval schema validation
├── tools/eval_runner.py      # deterministic prepare → ingest → score harness
├── tools/publish_routing_benchmark.py # sanitized, recomputable public evidence
├── tools/adapters/           # optional runtime and judge adapters
├── benchmarks/               # immutable runtime/model evidence packages
├── evals/schema.json         # shared JSON Schema for all skill evals
├── evals/run-schema.json     # manifests, responses, judgments, and results
├── BENCHMARK.md              # current result card, definitions, and limitations
├── EVALUATION.md             # adapter-neutral benchmark protocol
├── .claude-plugin/           # marketplace + plugin manifests
└── CASE_STUDIES.md           # reproducible or clearly labeled failure cases

Contributing

PRs welcome — see CONTRIBUTING.md. The bar: passes the linter, ships evals, doesn't duplicate a canonical rule, and ends with a verification protocol. Real-world catches belong in CASE_STUDIES.md only with reproducible, privacy-safe evidence.

License

MIT — use it, fork it, ship it. If this repo saved you from a silent spatial bug, a ⭐ helps others find it.