jbvc/postgresql
Design a PostgreSQL-specific schema. Covers best-practices, data types, indexing, constraints, performance patterns, and advanced features
59
59%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description identifies a clear domain (PostgreSQL schema design) and lists relevant topic areas, but it reads more like a course syllabus than an actionable skill description. It lacks explicit trigger guidance ('Use when...') and concrete actions, and misses common user-facing terms like 'database design', 'postgres', 'tables', or 'migrations'.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to design, review, or optimize a PostgreSQL database schema, create tables, or plan indexes.'
Include common trigger term variations such as 'postgres', 'database design', 'tables', 'migrations', 'CREATE TABLE', 'SQL schema', and 'DB design'.
Replace the passive 'Covers best-practices' phrasing with specific concrete actions like 'Designs table structures, selects appropriate data types, defines constraints and foreign keys, recommends indexing strategies, and applies performance optimization patterns.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (PostgreSQL schema design) and lists several areas it covers (data types, indexing, constraints, performance patterns, advanced features), but these are categories rather than concrete actions. It says 'Covers best-practices' rather than listing specific actions like 'creates migration files, defines foreign key relationships, generates index strategies.' | 2 / 3 |
Completeness | Describes what it does (design PostgreSQL schemas covering various topics) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' portion is also somewhat weak, so this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'PostgreSQL', 'schema', 'indexing', 'constraints', 'data types', and 'performance patterns' which users might mention. However, it misses common variations like 'database design', 'tables', 'migrations', 'SQL', 'postgres', 'DB schema', or 'CREATE TABLE'. | 2 / 3 |
Distinctiveness Conflict Risk | The PostgreSQL-specific qualifier helps distinguish it from general database or SQL skills, but 'schema design' could overlap with general database design skills, migration tools, or ORM-related skills. The broad coverage areas like 'performance patterns' and 'advanced features' add ambiguity. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive, highly actionable PostgreSQL schema design reference with excellent concrete examples and PostgreSQL-specific gotchas that genuinely add value beyond Claude's base knowledge. Its main weaknesses are its monolithic length (could benefit from splitting detailed sections into referenced files) and the lack of explicit validation checkpoints in the workflow for what are potentially destructive DDL operations. The 'Do not use' data types section and gotchas are particularly well-done additions.
Suggestions
Add explicit validation steps to the main workflow (e.g., 'Run EXPLAIN ANALYZE on key queries after index creation', 'Test DDL in transaction with ROLLBACK before committing') to create a proper feedback loop for schema changes.
Split detailed reference sections (Data Types, JSONB Guidance, Indexing, Partitioning) into separate referenced files to improve progressive disclosure and reduce the main skill's token footprint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is information-dense and mostly avoids explaining basics Claude already knows, but it's quite long with some sections that could be tightened (e.g., the TOAST storage details, extensive data type catalog). Some entries like network types and geometric types add marginal value given their brevity. However, most content is PostgreSQL-specific knowledge that genuinely adds value. | 2 / 3 |
Actionability | The skill provides concrete, executable SQL examples throughout—CREATE TABLE statements, CREATE INDEX commands, specific syntax for partitioning, JSONB indexing with operator classes, and complete table examples at the end. Guidance is specific (e.g., 'use BIGINT GENERATED ALWAYS AS IDENTITY', exact CHECK constraint syntax) rather than abstract. | 3 / 3 |
Workflow Clarity | The Instructions section provides a 5-step workflow but lacks explicit validation checkpoints. The 'Safe Schema Evolution' section mentions transactional DDL for testing but doesn't integrate validation into the main workflow. For destructive DDL operations, the Safety section mentions backups and rollback plans but doesn't provide a concrete validate-fix-retry loop, which should cap this at 2. | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear headers and logical sections, but it's a monolithic document with no references to external files for detailed topics. Sections like JSONB Guidance, Partitioning, and the full Data Types catalog could be split into separate reference files. For a skill of this length (~300+ lines), inline content would benefit from being split with navigation pointers. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents