tdg-personal/kotlin-ktor-patterns
Ktor server patterns including routing DSL, plugins, authentication, Koin DI, kotlinx.serialization, WebSockets, and testApplication testing.
63
63%
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 technology niche with strong Ktor-specific terminology that would help Claude distinguish it from other skills. However, it reads as a topic list rather than a capability description with concrete actions, and critically lacks any 'Use when...' guidance to tell Claude when to select this skill. Adding explicit trigger conditions and action verbs would significantly improve its effectiveness.
Suggestions
Add a 'Use when...' clause such as 'Use when the user is building or configuring a Ktor server, setting up routes, adding authentication, integrating dependency injection with Koin, or writing server tests.'
Rewrite the description to include concrete action verbs, e.g., 'Guides implementation of Ktor server applications including defining routes with the routing DSL, configuring plugins and authentication, integrating Koin for dependency injection, serializing data with kotlinx.serialization, implementing WebSocket endpoints, and writing integration tests with testApplication.'
Consider adding common user phrasings like 'Kotlin backend', 'Ktor API', or 'server-side Kotlin' to broaden trigger coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists several specific technologies and concepts (routing DSL, plugins, authentication, Koin DI, kotlinx.serialization, WebSockets, testApplication testing) but these are more like a feature list than concrete actions. It doesn't describe what actions are performed with these technologies (e.g., 'configure routes', 'set up authentication', 'write integration tests'). | 2 / 3 |
Completeness | Describes 'what' at a high level (Ktor server patterns involving various technologies) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also more of a topic list than a clear capability statement, warranting a 1. | 1 / 3 |
Trigger Term Quality | Contains strong natural keywords a developer would use: 'Ktor', 'routing DSL', 'plugins', 'authentication', 'Koin DI', 'kotlinx.serialization', 'WebSockets', 'testApplication'. These are the exact terms a Kotlin/Ktor developer would mention when seeking help. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of Ktor-specific terminology (routing DSL, testApplication, Koin DI, kotlinx.serialization) creates a very clear niche. It's unlikely to conflict with other skills unless there are multiple Ktor-related skills, as these terms are highly specific to the Ktor ecosystem. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive, highly actionable reference for Ktor server patterns with excellent executable code examples. Its main weaknesses are its monolithic length (everything inline, no progressive disclosure to sub-files) and lack of explicit workflow sequencing for multi-step processes like project setup or adding new endpoints. Trimming some boilerplate and splitting into focused sub-documents would significantly improve it.
Suggestions
Split into a concise SKILL.md overview with quick-start essentials, linking to separate files like ROUTING.md, AUTH.md, TESTING.md, and WEBSOCKETS.md for detailed patterns.
Add an explicit workflow section showing the step-by-step process for common tasks (e.g., 'Adding a new resource endpoint: 1. Create model, 2. Create repository, 3. Create service, 4. Add routes, 5. Register in Koin module, 6. Write tests').
Trim the project structure tree and the quick reference table — Claude can infer standard layouts, and the table largely duplicates what the code examples already demonstrate.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~500 lines) and includes some patterns Claude would already know (basic CRUD routing, standard project layouts). The project structure tree and some boilerplate could be trimmed. However, most code examples earn their place by showing Ktor-specific idioms. | 2 / 3 |
Actionability | Nearly all guidance is concrete, executable Kotlin code with proper imports context, realistic patterns, and copy-paste ready examples covering routing, auth, serialization, WebSockets, testing, and configuration. | 3 / 3 |
Workflow Clarity | The skill presents individual patterns clearly but lacks explicit workflow sequencing — there's no step-by-step guide for setting up a new Ktor project or adding a new feature end-to-end. The module() function implies ordering but doesn't explain why order matters (e.g., StatusPages before routing). | 2 / 3 |
Progressive Disclosure | Everything is in a single monolithic file with no references to external documents. At ~500 lines covering routing, auth, DI, WebSockets, testing, serialization, and configuration, this would benefit significantly from splitting into separate reference files with a concise overview in the main skill. | 1 / 3 |
Total | 8 / 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 (690 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