Add PostGIS skill with upstream sync checking

[cevian]

Summary

• Add PostGIS skill imported from gitea.osgeo.org/postgis/postgis, trimmed to PostGIS-specific content
• Add upstream-skills.json to track upstream sources with author attribution
• Add check script (npm run check:upstream-skills) to detect upstream changes
• Add GitHub Actions workflow to run weekly checks and create issues when upstream changes

Attribution

Thanks to Darafei Praliaskouski (@komzpa) for creating and maintaining the original PostGIS SKILL.md.

Test plan

• npm run check:upstream-skills runs successfully
• npm run lint passes
• npm run prettier:check passes

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[Komzpa]

Hi, as mentioned on the mailing list - I would prefer if the file is pulled in as is without silent manual edits on your side.

[cevian]

@Komzpa we'd need the upstream skill to really focus on Postgis to do that.

The general SQL/programming advice is not good for us in this file because we already have skills for that and we are super careful not to conflict with coding requirements that should be set at the project level (documentation, formatting, error reporting preferences etc.). The reason being that conflicts in context instruction increase hallucinations and do more harm than good.

Maybe upstream you can separate the skill into two - "Sql programming skill" and "Postgis skill"?

In particular we'd need the following removed from the postgis skill :

• Documentation section - not postgis specific and should be project-based requirements. I can see this easily conflict with project-based requirements and conflicts are what we really want to avoid since conflicting context really increases hallucinations.
• "Do not mix tabs and spaces in code"/"Add empty lines between logical blocks" That's not Postgis specific and can easily conflict with other project requirements. I'd also prefer to remove "Format the code nicely and consistently" but that has no harm.
• Create brin index for all columns - not postgis specific and I've seen lots of cases where this is bad advice.
• is the include recommendation specifically important for postgis fields, if so we should be a bit more explicit
• For the debugging section the postgis-specific stuff is great. But stuff like up and down/rollback migrations is not postgis specific and many systems don't do down migrations for a variety of reasons (they can often be unsafe in practice) again this should be a project based decision.
• SQL gotchas - again not postgis specific. I don't mind any of these but in an ideal world we can keep all of these in our desighn-postgres-schemas skill. But again it's not that big a deal just a preference for us to keep things clean.

The PostGIS gocthas are GOLD. This is really the heart of the skill.

[cevian]

@Komzpa ping?