kotlin-development
Kotlin development guidelines with best practices for clean code, naming conventions, function design, and data handling
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 ./kotlin-development/SKILL.mdQuality
Discovery
32%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 identifies its domain (Kotlin) and lists relevant topic areas, but lacks concrete actions and explicit trigger guidance. Without a 'Use when...' clause, Claude cannot reliably determine when to select this skill over other coding or style-related skills.
Suggestions
Add a 'Use when...' clause specifying triggers like 'when writing Kotlin code', 'when asking about Kotlin style', 'when reviewing .kt files', or 'when requesting idiomatic Kotlin'.
Replace category labels with concrete actions such as 'Applies Kotlin naming conventions, structures functions for readability, handles nullability patterns'.
Include natural keyword variations users might say: 'Kotlin style', 'idiomatic Kotlin', 'Kotlin conventions', '.kt files'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Kotlin development) and lists some areas (clean code, naming conventions, function design, data handling), but these are categories rather than concrete actions like 'format code' or 'refactor functions'. | 2 / 3 |
Completeness | Describes what the skill covers (Kotlin guidelines and best practices) but completely lacks any 'Use when...' clause or explicit trigger guidance for when Claude should select this skill. | 1 / 3 |
Trigger Term Quality | Includes 'Kotlin' which is a strong trigger term, and mentions relevant concepts like 'naming conventions' and 'clean code', but misses common variations users might say like 'Kotlin style', 'idiomatic Kotlin', '.kt files', or 'Kotlin best practices'. | 2 / 3 |
Distinctiveness Conflict Risk | The Kotlin focus provides some distinctiveness, but 'clean code', 'naming conventions', and 'function design' are generic enough to potentially overlap with other language-specific or general coding style skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a competent Kotlin style guide that provides clear conventions and guidelines, but it reads more like general programming best practices than Kotlin-specific guidance. The lack of concrete code examples reduces actionability, and some content (SOLID, testing conventions) explains concepts Claude already knows well.
Suggestions
Add concrete Kotlin code examples for key patterns (data class validation, RO-RO pattern implementation, custom exception types)
Remove or condense sections covering general programming knowledge Claude already has (SOLID principles, basic testing conventions)
Include Kotlin-specific idioms and features (sealed classes, extension functions, coroutines patterns) that differentiate this from generic guidelines
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably efficient but includes some guidance Claude already knows (SOLID principles, basic testing conventions, general OOP concepts). Some sections like 'Exception Handling Best Practices' state obvious practices. | 2 / 3 |
Actionability | Provides guidelines and rules but lacks concrete Kotlin code examples. Instructions like 'Use data classes for data structures' would benefit from executable code snippets showing proper implementation patterns. | 2 / 3 |
Workflow Clarity | For a guidelines/conventions skill, the content is well-organized with clear categorical structure. No multi-step processes requiring validation checkpoints exist here - it's a reference document with clear, unambiguous rules. | 3 / 3 |
Progressive Disclosure | Content is well-structured with clear sections, but it's a monolithic document that could benefit from splitting detailed sections (Testing, Exception Handling) into separate reference files with links from the main skill. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
68%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 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
body_examples | No examples detected (no code fences and no 'Example' wording) | Warning |
body_steps | No step-by-step structure detected (no ordered list); consider adding a simple workflow | Warning |
Total | 11 / 16 Passed | |
- Repository
- mindrally/skills
- Commit
47f47c1
- 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.