database-schema-design
Database schema design for PostgreSQL/MySQL with normalization, relationships, constraints. Use for new databases, schema reviews, migrations, or encountering missing PKs/FKs, wrong data types, premature denormalization, EAV anti-pattern.
63
75%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/database-schema-design/skills/database-schema-design/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly communicates both what the skill does and when to use it. It uses specific, natural trigger terms that developers would use, names concrete database platforms, and identifies specific anti-patterns as triggers. The description is concise yet comprehensive, making it easy for Claude to select appropriately from a large skill set.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: schema design, normalization, relationships, constraints, schema reviews, migrations. Also names specific anti-patterns like missing PKs/FKs, wrong data types, premature denormalization, and EAV anti-pattern. | 3 / 3 |
Completeness | Clearly answers both what ('Database schema design for PostgreSQL/MySQL with normalization, relationships, constraints') and when ('Use for new databases, schema reviews, migrations, or encountering missing PKs/FKs, wrong data types, premature denormalization, EAV anti-pattern'). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'database', 'schema', 'PostgreSQL', 'MySQL', 'normalization', 'migrations', 'PKs', 'FKs', 'data types', 'EAV'. These are terms a developer would naturally use when seeking database design help. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to database schema design for specific RDBMS platforms with distinct triggers like normalization, PKs/FKs, EAV anti-pattern. Unlikely to conflict with general coding skills or other data-related skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides excellent, executable SQL examples and covers database schema design comprehensively, but suffers severely from redundancy and verbosity. The same rules and patterns are repeated across multiple sections (Critical Rules, Top 7 Errors, Known Issues Prevention, Setup Checklist), inflating the token count without adding value. Content that should live in the referenced files (error catalog, type guide) is duplicated inline, undermining the progressive disclosure structure.
Suggestions
Eliminate redundant sections: merge 'Critical Rules', 'Top 7 Critical Errors', 'Known Issues Prevention', and 'Complete Setup Checklist' into a single concise checklist with one representative code example, moving detailed error examples to `references/error-catalog.md`.
Move the PostgreSQL/MySQL type reference and MySQL differences to `references/data-types-guide.md` and keep only 2-3 critical type choices inline (e.g., money as DECIMAL, dates as TIMESTAMPTZ).
Add a validation workflow: after creating/modifying a schema, include steps to verify constraints work (e.g., test INSERT with invalid data, verify CASCADE behavior, check index usage with EXPLAIN).
Provide the referenced bundle files (templates/*.sql, references/*.md) or remove the line-number references that currently point to non-existent files.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~350+ lines. Massive redundancy: the 'Critical Rules' tables duplicate the 'Top 7 Critical Errors' section, which duplicates the 'Known Issues Prevention' checklist, which duplicates the 'Complete Setup Checklist'. Normalization rules, data type recommendations, and anti-patterns are all things Claude already knows well. The same information (e.g., 'index all foreign keys', 'use audit columns') appears 4-5 times throughout. | 1 / 3 |
Actionability | Provides fully executable SQL examples throughout, with clear before/after comparisons. Code is copy-paste ready for both PostgreSQL and MySQL, with specific data types, constraints, indexes, and triggers. The production example is particularly well-constructed. | 3 / 3 |
Workflow Clarity | The 'Quick Start' provides a reasonable sequence and the 'Complete Setup Checklist' is useful, but there are no validation checkpoints or feedback loops. For schema design (which can involve destructive migrations), there's no guidance on testing schemas, validating migrations, or recovering from errors. The process is more of a reference than a guided workflow. | 2 / 3 |
Progressive Disclosure | References to templates and reference files are well-signaled and one-level deep, which is good. However, no bundle files are provided, so all those references are broken. Additionally, the SKILL.md itself is monolithic — much of the inline content (all 7 error examples, full type reference tables, MySQL differences) should be in the referenced files rather than duplicated in the main skill. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
- Repository
- secondsky/claude-skills
- Commit
5e92b71
- 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.