tdg-personal/kotlin-testing
Kotlin testing patterns with Kotest, MockK, coroutine testing, property-based testing, and Kover coverage. Follows TDD methodology with idiomatic Kotlin practices.
56
56%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
54%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 effectively identifies its niche through specific Kotlin testing tools and frameworks, making it highly distinctive. However, it reads more like a topic tag list than a functional description—it lacks concrete actions (verbs describing what the skill does) and entirely omits a 'Use when...' clause, which significantly hurts completeness and reduces Claude's ability to know when to select it.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to write Kotlin tests, set up test frameworks, mock dependencies, or configure code coverage.'
Replace the topic-listing style with concrete action verbs, e.g., 'Generates Kotest test suites, creates MockK mocks and stubs, configures Kover coverage reports, and writes property-based tests for Kotlin projects.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Kotlin testing) and several specific tools/frameworks (Kotest, MockK, Kover) and techniques (coroutine testing, property-based testing, TDD), but doesn't list concrete actions like 'write test cases', 'generate mocks', or 'configure coverage reports'. | 2 / 3 |
Completeness | Describes what (Kotlin testing patterns with specific tools) 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 more of a topic listing than a clear capability statement, warranting a score of 1. | 1 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Kotlin', 'testing', 'Kotest', 'MockK', 'coroutine testing', 'property-based testing', 'Kover', 'TDD', 'coverage'. These cover a good range of terms a developer would naturally use when seeking help with Kotlin testing. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of Kotlin-specific testing frameworks (Kotest, MockK, Kover) creates a very clear niche that is unlikely to conflict with general testing skills or other language-specific testing skills. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is highly actionable with excellent, executable code examples covering a comprehensive range of Kotlin testing patterns. However, it is severely over-long and verbose, explaining many concepts Claude already knows (TDD basics, what matchers do, best practices lists). The monolithic structure with no progressive disclosure to external files makes it a poor fit for a SKILL.md that should be a concise overview pointing to detailed references.
Suggestions
Reduce content by 60%+: remove the matchers reference section (Claude knows Kotest matchers), the DO/DON'T best practices list, the CI/CD example, and the RED/GREEN/REFACTOR ASCII diagram. Keep only patterns specific to this project's conventions.
Split into multiple files: move detailed examples (spec styles, MockK patterns, coroutine testing, property-based testing) into separate reference files and link to them from a concise SKILL.md overview.
Remove explanations of concepts Claude already knows, such as what TDD is, what suspend functions are, and how basic matchers work. Focus only on project-specific conventions and non-obvious patterns.
Add the testing commands and Kover config as separate quick-reference files rather than inlining them in the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This is extremely verbose at ~500+ lines. It explains basic concepts Claude already knows (what TDD is, what RED/GREEN/REFACTOR means, basic matcher usage like shouldBe). The matchers reference section, best practices DO/DON'T lists, and CI/CD example are all things Claude knows well. Much of this could be cut by 60-70% without losing actionable value. | 1 / 3 |
Actionability | The skill provides fully executable, copy-paste ready code examples throughout — Kotest specs, MockK patterns, coroutine testing, property-based testing, Kover configuration, and Ktor testing. Commands are specific and complete. | 3 / 3 |
Workflow Clarity | The TDD workflow is clearly sequenced with RED/GREEN/REFACTOR steps and includes verification commands. However, there are no validation checkpoints for potentially risky operations like coverage threshold failures or test flakiness detection. The overall document reads more like a reference catalog than a guided workflow. | 2 / 3 |
Progressive Disclosure | Everything is inlined in a single monolithic file with no references to external files. The quick reference section uses internal anchor links but all content (~500+ lines) is dumped into one document. Sections like matchers reference, CI/CD config, and detailed spec style examples should be split into separate files. | 1 / 3 |
Total | 7 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (825 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
Reviewed
Table of Contents