design-postgis-tables

Comprehensive PostGIS spatial table design reference covering geometry types, coordinate systems, spatial indexing, and performance patterns for location-based applications

Quality

76%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/design-postgis-tables/SKILL.md

Quality

Content

72%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, executable SQL reference with good in-file organization and minimal padding. Its weaknesses are the absence of explicit validation checkpoints (feedback loops) around database changes and the fully inlined reference material with no progressive disclosure into bundle files.

Suggestions

Add an explicit validation workflow (e.g., 1) create table + constraints, 2) EXPLAIN ANALYZE to confirm index usage, 3) if not used, adjust index/operator and re-check) so feedback loops are sequenced, not scattered.

Move the SRID tables, index-selection guide, and full schema examples into references/ files (one level deep, clearly linked from SKILL.md) to enable progressive disclosure.

De-duplicate the SQL-injection guidance (keep it once, either in the intro note or in Common Pitfalls) and trim the "Use X for:" lists that restate the inline code comments.

Dimension	Reasoning	Score
Conciseness	Mostly lean SQL blocks, tables, and bullet lists that assume PostGIS knowledge, with only minor trims available (the SQL-injection note is restated in "Common Pitfalls", and the "Use X for:" lists repeat the code comments). Not 5 due to that duplication; not 3 because there is no padding explaining concepts Claude already knows.	4 / 5
Actionability	Fully executable, copy-paste-ready DDL and DML: complete CREATE TABLE statements with constraints and generated columns, index creation for each type, and realistic queries covering the common cases (POI radius search, parcel intersect, GPS track assembly, zone containment).	5 / 5
Workflow Clarity	"Before You Start (5 Questions)" and "Core Rules" provide ordering, and validation is mentioned (run EXPLAIN ANALYZE, ST_IsValidReason -> ST_MakeValid), but these are scattered tips rather than explicit validate-then-fix-then-retry checkpoints; the rubric caps workflow clarity at 3 for database-operation skills lacking feedback loops. Not 2 because a decision sequence and validation content do exist.	3 / 5
Progressive Disclosure	A single ~495-line file with clear section headers but zero external references: the SRID tables, index-selection guide, and four full schema examples are reference material that belongs in separate files, matching the some-structure-but-should-be-split anchor. Not 4 because nothing is offloaded to a references/ bundle; not 2 because in-file organization and navigation are good.	3 / 5
	Total	15 / 20 Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A domain-specific, well-scoped description with good keyword coverage, but it lacks any explicit "Use when..." trigger guidance, capping its completeness. Adding a trigger clause naming the situations and terms (PostGIS, spatial data, GIS/PostgreSQL schemas) would lift the two weakest dimensions.

Suggestions

Append an explicit trigger clause such as: "Use when designing spatial database schemas, creating geometry/geography columns, or working with PostGIS, GIS, or geospatial data in PostgreSQL."

Include common user synonyms ("GIS", "geospatial", "PostgreSQL", "lat/lon") in the description to improve trigger-term coverage.

Mention data validation and SRID selection in the coverage list to align the description with the body's actual scope.

Dimension	Reasoning	Score
Specificity	Names the domain and four concrete coverage areas ("geometry types, coordinate systems, spatial indexing, and performance patterns"), matching the several-specific-items-with-minor-gaps anchor. Not 5 because the items are topic nouns rather than multiple concrete actions and coverage omits areas present in the body (e.g., data validation); not 3 because it goes well beyond naming 1-2 actions.	4 / 5
Completeness	The "what" is clear (a PostGIS spatial table design reference with enumerated coverage), but there is no "Use when..." clause — only the weakly implied "for location-based applications" — which the guidelines cap at 3. Not 2 because the what is explicit, not vague; not 4 because no explicit trigger guidance exists at all.	3 / 5
Trigger Term Quality	Natural keywords users would say are present ("PostGIS", "spatial", "geometry", "indexing", "location-based"), but common synonyms like "GIS", "geospatial", and "PostgreSQL" are missing, fitting the good-coverage-with-a-few-missing anchor.	4 / 5
Distinctiveness Conflict Risk	"PostGIS spatial table design" is a clear niche with distinct triggers unlikely to collide with other skills, matching the minimal-conflict-risk anchor.	5 / 5
	Total	16 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: timescale/pg-aiguide
Path: skills/design-postgis-tables/SKILL.md
Commit: b236d35

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.