defense-in-depth-validation
Validate at every layer data passes through to make bugs impossible. Use when invalid data causes failures deep in execution, requiring validation at multiple system layers.
78
72%
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/defense-in-depth-validation/skills/defense-in-depth-validation/SKILL.mdQuality
Discovery
67%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 has good structural completeness with an explicit 'Use when' clause, but suffers from moderate vagueness in its capabilities and somewhat aspirational language ('make bugs impossible'). It would benefit from listing specific validation techniques and including more natural trigger terms that users would actually use when seeking this kind of help.
Suggestions
Add specific concrete actions such as 'add input validation, enforce type contracts, validate schemas at API boundaries, implement guard clauses'.
Include more natural trigger terms users would say, such as 'input validation', 'schema validation', 'type checking', 'defensive programming', 'data sanitization', or 'runtime checks'.
Replace the aspirational phrase 'make bugs impossible' with a more precise description of the outcome, such as 'catch invalid data early before it propagates through the system'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a domain (data validation across layers) and a general action ('validate at every layer data passes through'), but lacks specific concrete actions like 'add type checks', 'validate schemas', 'sanitize inputs', or 'enforce contracts at API boundaries'. | 2 / 3 |
Completeness | The description answers both 'what' (validate at every layer data passes through to make bugs impossible) and 'when' (use when invalid data causes failures deep in execution, requiring validation at multiple system layers) with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'validation', 'invalid data', 'failures', and 'multiple system layers', but misses common natural variations users might say such as 'input validation', 'schema validation', 'type checking', 'data sanitization', 'defensive programming', or 'guard clauses'. | 2 / 3 |
Distinctiveness Conflict Risk | The concept of multi-layer validation is somewhat specific, but 'validation' is a broad concept that could overlap with skills related to testing, error handling, type systems, or input sanitization. The phrase 'make bugs impossible' is vague and aspirational rather than distinctive. | 2 / 3 |
Total | 9 / 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, actionable skill that teaches a clear defensive validation pattern with concrete TypeScript examples at each layer. Its main weakness is some verbosity in motivational framing and restated conclusions that don't add new information. The workflow and examples are strong, making this practically useful despite the minor conciseness issues.
Suggestions
Remove or condense the 'Why Multiple Layers' section and the 'Key Insight' section—they restate the core principle without adding actionable guidance.
Trim motivational framing like 'feels sufficient' and 'We fixed the bug' vs 'We made the bug impossible' to save tokens while preserving clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some unnecessary explanation. The 'Why Multiple Layers' section and the motivational framing ('feels sufficient', 'We fixed the bug' vs 'We made the bug impossible') add tokens without adding actionable value. The 'Key Insight' section at the end largely restates what was already demonstrated. | 2 / 3 |
Actionability | Provides fully executable TypeScript code examples for each of the four validation layers, with concrete patterns that can be directly adapted. The 'Applying the Pattern' section gives a clear step-by-step process, and the real-world example shows exactly how to trace and fix a bug. | 3 / 3 |
Workflow Clarity | The four-layer framework is clearly sequenced with distinct purposes. The 'Applying the Pattern' section provides an explicit 4-step workflow including testing/verification ('Test each layer - Try to bypass layer 1, verify layer 2 catches it'). The concrete example traces the full data flow and maps fixes to each layer. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and sections, but it's somewhat long for a single file with no references to external resources. The detailed example and key insight sections could potentially be split out. However, for a conceptual pattern skill, the inline approach is reasonable. | 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.
- Repository
- secondsky/claude-skills
- Commit
88da5ff
- 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.