postgresql-table-design
Design a PostgreSQL-specific schema. Covers best-practices, data types, indexing, constraints, performance patterns, and advanced features
Install with Tessl CLI
npx tessl i github:Dicklesworthstone/pi_agent_rust --skill postgresql-table-design69
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
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 the domain (PostgreSQL schema design) and lists relevant topic areas, but lacks concrete action verbs and completely omits trigger guidance for when to use this skill. The coverage of natural user terms is limited, missing common variations like 'Postgres' or 'database design'.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when designing PostgreSQL databases, creating tables, or when the user mentions Postgres, database schema, or table design'.
Replace category nouns with concrete actions: 'Creates tables with appropriate data types, defines indexes for query optimization, implements constraints and foreign keys'.
Include common term variations: 'Postgres', 'database design', 'table structure', 'DDL', 'CREATE TABLE'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (PostgreSQL schema design) and lists several action areas (data types, indexing, constraints, performance patterns, advanced features), but these are categories rather than concrete actions like 'create indexes' or 'define foreign key constraints'. | 2 / 3 |
Completeness | Describes what the skill covers but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing explicit trigger guidance caps this at 2, but the 'what' is also only moderately clear, warranting a 1. | 1 / 3 |
Trigger Term Quality | Includes 'PostgreSQL' and 'schema' which users would naturally say, but misses common variations like 'Postgres', 'database design', 'table structure', 'DDL', or 'database schema'. | 2 / 3 |
Distinctiveness Conflict Risk | PostgreSQL-specific focus provides some distinction from generic database skills, but could overlap with general SQL skills, database optimization skills, or other database design tools without clearer trigger boundaries. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
79%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality PostgreSQL schema design reference that excels in actionability and conciseness—it provides specific, executable guidance without unnecessary explanation. The main weaknesses are the lack of explicit validation workflows for schema changes and the monolithic structure that could benefit from progressive disclosure through linked reference files for advanced topics.
Suggestions
Add explicit validation workflows for schema evolution (e.g., 'Before ALTER TABLE: 1. Check dependencies with pg_depend, 2. Test in transaction, 3. Verify with \d tablename')
Split advanced sections (Partitioning, Extensions, JSONB Guidance) into separate reference files with clear links from the main skill
Add a verification checklist for table creation covering common mistakes (FK indexes, constraint validation, index coverage)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is dense and efficient, avoiding explanations of basic concepts Claude already knows. Every section provides specific PostgreSQL knowledge without padding—data types, gotchas, and patterns are presented as actionable reference material. | 3 / 3 |
Actionability | Provides fully executable SQL examples throughout, specific syntax for indexes, constraints, and table creation. The examples section includes copy-paste ready code for common patterns (users, orders, JSONB profiles). | 3 / 3 |
Workflow Clarity | While individual sections are clear, the skill lacks explicit validation checkpoints for schema changes. The 'Safe Schema Evolution' section mentions transactional DDL but doesn't provide a clear step-by-step workflow with verification steps for destructive operations. | 2 / 3 |
Progressive Disclosure | Content is well-organized with clear headers, but it's a monolithic document (~300 lines) that could benefit from splitting advanced topics (partitioning, extensions, JSONB guidance) into separate reference files. No external file references are provided. | 2 / 3 |
Total | 10 / 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
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.