Agent skill for production-validator - invoke with $agent-production-validator
40
7%
Does it follow best practices?
Impact
98%
1.22xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/agent-production-validator/SKILL.mdQuality
Discovery
0%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 description is critically deficient across all dimensions. It functions only as an invocation instruction ('invoke with $agent-production-validator') rather than a skill description, providing zero information about what the skill does, when to use it, or what domain it covers. It would be nearly impossible for Claude to correctly select this skill from a pool of available options.
Suggestions
Add concrete actions describing what the skill does, e.g., 'Validates production deployments by checking service health, configuration correctness, and endpoint availability.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks to validate a production environment, check deployment readiness, or verify production configuration.'
Include natural keywords users would actually say, such as 'production check', 'deployment validation', 'health check', 'production readiness', or whatever the actual domain is.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description provides no concrete actions whatsoever. 'Agent skill for production-validator' is entirely vague—it doesn't describe what the skill actually does, only names itself. | 1 / 3 |
Completeness | Neither 'what does this do' nor 'when should Claude use it' is answered. The description only states it's an agent skill and how to invoke it, providing no functional or contextual information. | 1 / 3 |
Trigger Term Quality | The only keyword is 'production-validator', which is a technical/internal name, not a natural term a user would say. There are no natural language trigger terms like 'validate', 'deploy', 'check production', etc. | 1 / 3 |
Distinctiveness Conflict Risk | The description is so vague that it's impossible to distinguish it from other skills. 'Production-validator' could overlap with testing, deployment, CI/CD, or any validation-related skill. | 1 / 3 |
Total | 4 / 12 Passed |
Implementation
14%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is an overly verbose collection of generic TypeScript test templates and bash commands that Claude already knows how to produce. It lacks a clear sequential workflow, has no validation checkpoints or feedback loops, and dumps everything into a single monolithic file. The content would benefit enormously from being condensed to a concise checklist-driven workflow with references to separate files for detailed examples.
Suggestions
Replace the extensive code templates with a concise, numbered validation workflow (e.g., 1. Scan for mocks → 2. Verify env vars → 3. Run integration tests → 4. Validate performance → 5. Security check) with explicit pass/fail criteria and feedback loops at each step.
Remove generic test examples that Claude can already write (CRUD tests, Redis get/set, basic auth tests) and instead provide only project-specific patterns, thresholds, or non-obvious configuration details.
Split detailed code examples into separate reference files (e.g., EXAMPLES.md, CHECKLIST.md) and keep SKILL.md as a lean overview with clear navigation links.
Add explicit validation gates and error recovery steps: what constitutes a pass/fail at each stage, and what to do when a check fails before proceeding to the next step.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~300+ lines. Most code examples are illustrative templates that Claude already knows how to write (standard Jest tests, CRUD operations, Redis get/set, etc.). The content explains obvious concepts like what mock patterns look like and how to do basic database CRUD, which wastes significant token budget. | 1 / 3 |
Actionability | The code examples are syntactically reasonable TypeScript/Jest patterns, but they are generic templates rather than executable, project-specific guidance. They reference undefined variables (e.g., `app`, `validToken`), unspecified project structures, and environment variables without concrete setup instructions. The bash grep commands in the checklist section are the most directly actionable parts. | 2 / 3 |
Workflow Clarity | There is no clear sequential workflow for performing production validation. The content is organized as a catalog of test examples and checklists but lacks a defined process: what to do first, how to proceed, when to stop, and what to do when validation fails. No feedback loops or error recovery steps are defined despite the destructive/critical nature of production validation. | 1 / 3 |
Progressive Disclosure | The entire skill is a monolithic wall of text with no references to external files and no layered structure. All content—from basic grep commands to detailed load testing code—is dumped inline. There's no separation between quick-reference overview and detailed examples, and no bundle files to support progressive disclosure. | 1 / 3 |
Total | 5 / 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.
9d4a9ea
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.