Process use when you need to ensure database integrity through comprehensive data validation. This skill validates data types, ranges, formats, referential integrity, and business rules. Trigger with phrases like "validate database data", "implement data validation rules", "enforce data integrity constraints", or "validate data formats".
82
79%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/database/data-validation-engine/skills/validating-database-integrity/SKILL.mdQuality
Discovery
82%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 reasonably well-constructed skill description that clearly communicates both what it does and when to use it, with explicit trigger phrases. Its main weaknesses are that the capabilities listed are somewhat categorical rather than deeply specific concrete actions, and the domain could overlap with adjacent database or data quality skills. The opening 'Process use when' phrasing is awkward and could be cleaner.
Suggestions
Replace categorical capability descriptions with more concrete actions, e.g., 'Checks foreign key references, validates email/phone formats, enforces numeric ranges, verifies NOT NULL constraints' instead of listing abstract categories.
Sharpen distinctiveness by specifying what differentiates this from general database management or data cleaning skills—e.g., clarify if this is about writing validation code, running validation checks, or designing constraint schemas.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (database integrity/data validation) and lists some categories of validation (data types, ranges, formats, referential integrity, business rules), but these are still somewhat categorical rather than concrete specific actions like 'check foreign key constraints' or 'validate email format patterns'. | 2 / 3 |
Completeness | The description clearly answers both 'what' (validates data types, ranges, formats, referential integrity, and business rules for database integrity) and 'when' (explicit trigger phrases provided with 'Trigger with phrases like...'). | 3 / 3 |
Trigger Term Quality | The description includes explicit trigger phrases that users would naturally say: 'validate database data', 'implement data validation rules', 'enforce data integrity constraints', 'validate data formats'. These cover good natural language variations. | 3 / 3 |
Distinctiveness Conflict Risk | While it focuses on database data validation specifically, it could overlap with general database management skills, schema validation skills, or data quality/cleaning skills. The scope of 'business rules' is broad enough to potentially conflict with other skills. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, highly actionable skill with a well-sequenced workflow and explicit validation checkpoints. Its main weakness is length—the content is comprehensive but could benefit from splitting detailed examples, error handling, and resources into separate referenced files. Some prose could be trimmed to improve token efficiency.
Suggestions
Extract the error handling table, detailed examples, and resources into separate referenced files (e.g., ERRORS.md, EXAMPLES.md) to improve progressive disclosure and reduce the main file's token footprint.
Trim the prerequisites section—Claude doesn't need to be told what psql is or that backups are important; focus on non-obvious requirements like the NOT VALID permission requirement.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly comprehensive but includes some unnecessary verbosity—prerequisites like explaining what a backup is, narrative examples that could be shorter, and the error handling table restates things that are somewhat obvious to Claude. The SQL examples themselves are efficient, but the surrounding prose could be tightened. | 2 / 3 |
Actionability | The skill provides fully executable SQL commands for every step—validation queries, ALTER TABLE statements, regex patterns, and specific constraint syntax for both PostgreSQL and MySQL. The two-phase approach with NOT VALID is a concrete, copy-paste-ready technique. | 3 / 3 |
Workflow Clarity | The 10-step workflow is clearly sequenced: audit first, detect violations, clean up data, then apply constraints in a safe two-phase approach. Step 9 explicitly includes a validation/feedback loop (NOT VALID then VALIDATE CONSTRAINT), and step 2 requires documenting orphans before adding FK constraints. The error handling table provides recovery paths for common failures. | 3 / 3 |
Progressive Disclosure | The content is a long monolithic document (~150+ lines) with no references to supporting files. The error handling table, examples section, and resources could be split into separate files. For a skill of this complexity, inline everything makes it harder to navigate, though the section headers provide reasonable structure. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
3a2d27d
Table of Contents
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.