Language-agnostic testing principles including TDD, test quality, coverage standards, and test design patterns. Use when writing tests, designing test strategies, or reviewing test quality.
56
47%
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 ./skills/testing-principles/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 is structurally sound with a clear 'Use when...' clause and covers the testing domain adequately. Its main weaknesses are that the capabilities listed are somewhat abstract categories rather than concrete actions, and the trigger terms could be more comprehensive to include common user phrasings like 'unit test', 'mock', or 'test-driven development'.
Suggestions
Replace abstract categories with concrete actions, e.g., 'Guides writing unit tests, integration tests, and mocks; applies TDD workflows; evaluates test coverage and quality'.
Expand trigger terms to include common variations users would say: 'unit tests', 'integration tests', 'mocking', 'test-driven development', 'test cases', 'assertions'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (testing) and lists some areas like TDD, test quality, coverage standards, and test design patterns, but these are still somewhat abstract categories rather than concrete actions like 'write unit tests, generate mocks, measure code coverage'. | 2 / 3 |
Completeness | Clearly answers both 'what' (language-agnostic testing principles including TDD, test quality, coverage standards, and test design patterns) and 'when' (Use when writing tests, designing test strategies, or reviewing test quality) with an explicit 'Use when...' clause. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'TDD', 'tests', 'test strategies', 'test quality', and 'coverage', which users might naturally say. However, it misses common variations like 'unit tests', 'integration tests', 'mocking', 'assertions', 'test cases', or 'test-driven development' spelled out. | 2 / 3 |
Distinctiveness Conflict Risk | The testing focus is reasonably distinct, but 'language-agnostic' and broad terms like 'test quality' and 'test design patterns' could overlap with language-specific testing skills or general code quality/review skills. It doesn't clearly carve out a unique niche versus, say, a Python testing skill or a code review skill. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads like a comprehensive testing textbook rather than a targeted skill file for Claude. It extensively explains well-known concepts (test pyramid, TDD, mocking types, AAA pattern) that Claude already understands, consuming enormous token budget without adding novel or project-specific value. The content would benefit dramatically from being reduced to project-specific standards and conventions, with common knowledge removed entirely.
Suggestions
Remove all explanations of concepts Claude already knows (TDD basics, what unit/integration/e2e tests are, test pyramid, types of test doubles, AAA pattern) and keep only project-specific standards and thresholds.
Reduce the document to under 100 lines focusing on: coverage thresholds, naming conventions, directory structure, and the specific anti-patterns/quality criteria unique to this project.
Split detailed sections (data layer testing, mocking guidelines, paradigm-specific advice) into separate referenced files to enable progressive disclosure.
Add concrete, executable examples in at least one language rather than pseudocode, or explicitly state this is meant to be paired with language-specific skill files.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This is extremely verbose at ~400+ lines, extensively explaining concepts Claude already knows well (TDD cycle, AAA pattern, test pyramid, types of test doubles, what unit/integration/e2e tests are). The vast majority of content is textbook testing knowledge that adds no novel information. | 1 / 3 |
Actionability | Provides some concrete guidance with pseudocode examples and clear patterns (AAA, naming conventions), but being language-agnostic means no executable code exists. Examples are illustrative rather than copy-paste ready, and many sections are descriptive rather than instructive. | 2 / 3 |
Workflow Clarity | The TDD RED-GREEN-REFACTOR cycle is clearly sequenced with a verification step, and the before-commit checklist is useful. However, there are no feedback loops for error recovery, and the workflow steps are generic descriptions rather than concrete actionable sequences. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files for detailed content. Everything is inlined in one massive document. References to 'Test Independence Verification' appear to be internal cross-references to a section within the same file rather than progressive disclosure to separate documents. | 1 / 3 |
Total | 6 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (514 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
2e719be
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.