Android Kotlin development with Coroutines, Jetpack Compose, Hilt, and MockK testing
35
31%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/android-kotlin/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 reads more like a tag list of technologies than a proper skill description. It lacks concrete actions describing what the skill enables Claude to do and entirely omits a 'Use when...' clause, making it difficult for Claude to know when to select this skill over others. The technology keywords provide some value for matching but are insufficient on their own.
Suggestions
Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks about Android app development, Jetpack Compose UI, Hilt dependency injection, coroutine-based async code, or MockK unit testing.'
List specific concrete actions the skill covers, e.g., 'Builds Android UIs with Jetpack Compose, configures Hilt dependency injection modules, writes coroutine-based async logic, and creates unit tests with MockK.'
Include common user-facing variations like 'Android app', 'mobile development', 'Compose UI', 'dependency injection', 'async/suspend functions', and 'unit testing' to improve trigger term coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Android Kotlin development) and lists specific technologies (Coroutines, Jetpack Compose, Hilt, MockK testing), but does not describe concrete actions like 'build UI components', 'write unit tests', or 'set up dependency injection'. | 2 / 3 |
Completeness | Provides a partial 'what' (Android Kotlin development with specific libraries) but completely lacks any 'when' clause or explicit trigger guidance for when Claude should select this skill. | 1 / 3 |
Trigger Term Quality | Includes relevant technology keywords (Kotlin, Coroutines, Jetpack Compose, Hilt, MockK) that users might mention, but misses common variations and broader terms like 'Android app', 'mobile development', 'UI testing', 'dependency injection', or 'async programming'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of Android + Kotlin + specific libraries (Compose, Hilt, MockK) provides some distinctiveness, but 'Android Kotlin development' is broad enough to overlap with other potential Android or Kotlin skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
29%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more like a comprehensive Android Kotlin reference/cheat sheet than an actionable skill for Claude. While the code examples are high quality and executable, the document is bloated with boilerplate (full Gradle configs, CI pipelines, lint configs) that Claude already knows, lacks any workflow guidance for performing tasks, and dumps everything into a single monolithic file with no progressive disclosure.
Suggestions
Remove or drastically trim boilerplate sections (Gradle config, GitHub Actions, detekt.yml) that Claude can generate from basic instructions — focus only on project-specific conventions or non-obvious patterns.
Add workflow sections with clear step-by-step sequences, e.g., 'Adding a new feature screen: 1. Create domain model → 2. Define repository interface → 3. Implement repository → 4. Create use case → 5. Build ViewModel → 6. Write Compose screen → 7. Add Hilt module → 8. Write tests'.
Split content into separate reference files (e.g., TESTING.md, COMPOSE_PATTERNS.md, GRADLE.md) and keep SKILL.md as a concise overview with links to each.
Add validation checkpoints to workflows, such as 'Run ./gradlew testDebugUnitTest after adding repository implementation' or 'Verify Hilt graph compiles before adding UI layer'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~400+ lines, including full Gradle configurations, complete project structure trees, CI/CD pipelines, and lint configs that Claude already knows or can generate. Much of this is boilerplate reference material that doesn't add unique value — Claude knows how to set up Android projects, write Gradle files, and configure GitHub Actions. | 1 / 3 |
Actionability | The code examples are fully executable and copy-paste ready — complete ViewModel implementations, repository patterns with Flow, Compose screens, test classes with MockK/Turbine, and working Gradle configurations. Every section provides concrete, runnable code rather than abstract descriptions. | 3 / 3 |
Workflow Clarity | There is no workflow or sequenced process described. The skill is a collection of reference patterns and code snippets organized by topic, but lacks any step-by-step guidance for creating features, debugging, or performing multi-step operations. There are no validation checkpoints or feedback loops. | 1 / 3 |
Progressive Disclosure | The content is a monolithic wall of text with no references to external files and no layered structure. Everything from basic Gradle config to testing patterns to CI/CD is dumped inline. The Gradle config, CI pipeline, and detekt config could easily be separate reference files, with the main skill focusing on patterns and workflows. | 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
7e5f7a2
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.