Content
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 |