Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.
62
62%
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 (database design) and lists relevant subtopics, but reads more like a tag list than an actionable skill description. It lacks concrete action verbs describing what the skill does and entirely omits a 'Use when...' clause, making it difficult for Claude to know when to select this skill over others.
Suggestions
Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks about database schema design, choosing between SQL and NoSQL, indexing strategies, ORM selection, or serverless database options.'
Replace topic labels with concrete action phrases, e.g., 'Designs database schemas, recommends indexing strategies, evaluates ORM tradeoffs, and advises on serverless database selection.'
Include additional natural trigger terms users might say, such as 'SQL', 'NoSQL', 'normalization', 'query performance', 'data modeling', or specific database names like 'PostgreSQL' or 'DynamoDB'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (database design) and lists several specific areas (schema design, indexing strategy, ORM selection, serverless databases), but these are more like topic labels than concrete actions. It doesn't describe what actions are performed (e.g., 'designs schemas', 'recommends indexes', 'evaluates ORM tradeoffs'). | 2 / 3 |
Completeness | Describes 'what' at a high level (database design principles and decision-making) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also weak enough to warrant a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'database', 'schema design', 'indexing', 'ORM', and 'serverless databases' that users might mention. However, it misses common variations like 'SQL', 'NoSQL', 'PostgreSQL', 'MySQL', 'database migration', 'normalization', 'query optimization', or 'data modeling'. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on database design principles, ORM selection, and serverless databases provides some distinctiveness, but 'schema design' and 'indexing strategy' could overlap with general backend development or SQL-focused skills. Without clearer boundaries, there's moderate conflict risk. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured overview/routing skill that excels at progressive disclosure and conciseness. Its main weakness is the lack of any concrete, executable guidance in the main file itself—it relies entirely on sub-files for actionable content. The decision checklist is helpful but could benefit from validation steps or a clearer workflow sequence for database design decisions.
Suggestions
Add at least one concrete, executable example in the main file (e.g., a quick-start schema snippet or a sample Drizzle/Prisma config) to improve actionability.
Add a validation/verification step to the decision checklist, such as 'Verified schema with EXPLAIN ANALYZE on key queries?' to strengthen workflow clarity for potentially destructive operations like migrations.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Very lean and efficient. No unnecessary explanations of what databases are or how ORMs work. Every line serves a purpose—content map, decision checklist, anti-patterns are all tightly written. | 3 / 3 |
Actionability | The content provides a decision checklist and anti-patterns which are somewhat actionable, but lacks any concrete code examples, specific commands, or executable guidance. It's more of a routing/overview document that delegates all concrete content to sub-files. | 2 / 3 |
Workflow Clarity | The decision checklist provides a sequence of considerations before designing a schema, but there are no validation checkpoints or feedback loops. For database design (which can involve destructive migrations), the lack of explicit verification steps is a gap. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure with a clear content map table showing 6 sub-files, each with a description and 'When to Read' guidance. The selective reading rule is well-signaled, and references are one level deep with clear navigation. | 3 / 3 |
Total | 10 / 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 |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents