GeoAI Skills: 18 open Agent Skills for safer geospatial workflows

Question

Hi Esri Community,

I’m sharing the first public preview of GeoAI Skills, an open-source suite of 18 Agent Skills designed to help AI agents produce safer and more defensible geospatial workflows.

The project focuses on silent spatial failures: errors that do not crash the workflow but can still make the result methodologically invalid.

Examples include:

• calculating area or distance in a geographic CRS
• using random train/test splits on spatial data
• comparing misaligned raster datasets
• reporting model outputs without uncertainty or verification
• generating maps that render correctly but use unsuitable projections

The suite covers geospatial data engineering, PostGIS, remote sensing, Google Earth Engine, GeoAI and deep learning, spatial statistics, geostatistics, terrain and hydrology, LiDAR, accessibility, trajectories, change detection, cartography, and guarded ArcGIS Pro automation.

The ArcGIS Pro skill works with my open-source arcgis-mcp-bridge project for controlled local ArcPy execution, including path restrictions and confirmation gates for mutating operations.

The repository currently includes 131 typed evaluation scenarios.

On a frozen 17-skill, 120-case Claude Code / Claude Sonnet 5 routing benchmark, it achieved:

• 100% routing precision
• 92.86% routing recall
• 92.5% full-route accuracy

These figures measure routing for that specific runtime and evaluation suite, not universal answer quality.

Install:

npx skills add muend/geoai-skills

Repository:
https://github.com/muend/geoai-skills

Public preview:
https://github.com/muend/geoai-skills/releases/tag/v0.1.0-preview.1

I would appreciate feedback on two areas:

1. Which common ArcGIS Pro, ArcPy, or general GIS failure modes are still missing?
2. Which real-world workflows would make useful evaluation cases?

Reproducible examples, technical criticism, and contributions are welcome.

Thank you.

social-preview.jpg

muend · Answer

Thank you — both suggestions land, and the second one raises a question I don't have a good answer to yet.

On data-quality validation. Part of this exists, and I'd rather point you at it than claim it. geo-data-engineering defines a hygiene pass — drop empty/null geometries, make_valid the invalid ones, de-duplicate, reproject, and print a row-count accounting so nothing disappears quietly. Its stated failure mode is to quarantine ambiguous CRS, mixed units and lossy conversions rather than guess. Four eval cases exercise it: messy-shapefile, crs-loss-audit (marked critical), unknown-source-schema, and contractor-delivery-lineage-gate — the last one is a GeoPackage that must ship tonight with CRS, licence and extraction date only vaguely described in an email.

Where you're right is the sequencing. Today those checks fire when the work routes to that skill. There is no preflight gate that runs before any analysis regardless of what was asked — so an invalid-geometry problem reaching a suitability analysis directly can still slip through. That's a real gap and a better design than what I have. I'll write it up as an issue rather than promise a version.

On enterprise and API-triggered workflows. Out of scope today, deliberately: arcgis-pro-automation explicitly excludes ArcGIS Online and Enterprise administration and targets local Pro/ArcPy through a guarded bridge. Widening that is a bigger commitment than adding cases.

But your point exposes something I haven't solved. This project's whole premise is that a skill stops and states why when the data can't support the claim. In an unattended pipeline triggered from Salesforce there's nobody to stop for. So what is a refusal there — a failed job, a flagged record with a provisional value, a written justification attached to the output, something else? Whichever answer is right changes the design, not just the test coverage.

If you've seen how organisations actually handle a "the analysis cannot be run as specified" outcome inside an automated GIS process, I'd genuinely rather learn that than guess at it.

One caveat worth stating: the published benchmark measures routing — which skill activates — not whether the resulting analysis is correct. Answer quality has never been measured, and that's on the card too.

TomMethews · Answer

Thanks for sharing this project. The emphasis on preventing silent spatial errors is a great addition, as those issues can easily go unnoticed while still affecting the accuracy of the final results.

One suggestion would be to include validation checks for common data quality problems before analysis starts, such as invalid geometries, missing spatial references, duplicate features, or mismatched coordinate systems. Catching these early can help avoid unreliable outputs.

For evaluation scenarios, it could also be valuable to cover enterprise workflows where ArcGIS integrates with business applications like Salesforce. Many organizations rely on automated GIS processes triggered through APIs, so testing those use cases would make the project even more relevant for real-world deployments.

Looking forward to seeing how the project develops. Thanks again for making it available to the community.

Salesforce Consulting

muend · Answer

The complete collection is also available on skills.sh:

https://www.skills.sh/muend/geoai-skills

The suite can be installed interactively with:

npx skills add muend/geoai-skills