Design Android repositories with feature, core, and build-logic modules that scale without cyclic dependencies.
49
37%
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 ./.github/skills/android-modularization/SKILL.mdQuality
Discovery
40%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 a clear niche in Android multi-module architecture design and mentions specific module types, giving it good distinctiveness. However, it lacks a 'Use when...' clause, which significantly hurts completeness, and the concrete actions are limited to the single verb 'design'. Adding explicit trigger guidance and more natural user keywords would substantially improve skill selection accuracy.
Suggestions
Add a 'Use when...' clause with trigger terms like 'Use when the user asks about Android modularization, multi-module project structure, Gradle module setup, or avoiding circular dependencies.'
Include more natural keywords users would say, such as 'multi-module', 'modularization', 'Gradle', 'module dependencies', 'project structure', and 'convention plugins'.
List more specific concrete actions, e.g., 'Designs module dependency graphs, configures build-logic convention plugins, sets up feature/core/data module boundaries, and resolves cyclic dependency issues.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Android repositories) and mentions specific module types (feature, core, build-logic), but doesn't list multiple concrete actions beyond 'design' — lacks specifics like dependency management techniques, module creation steps, or configuration details. | 2 / 3 |
Completeness | Describes what the skill does (design Android repositories with specific module types) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing 'Use when' caps completeness at 2, and the 'what' is also only moderately detailed, warranting a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant terms like 'Android', 'repositories', 'feature modules', 'core modules', 'build-logic modules', and 'cyclic dependencies', but misses common user variations like 'multi-module project', 'modularization', 'Gradle', 'module structure', or 'monorepo'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of Android, multi-module architecture with specific module types (feature, core, build-logic), and cyclic dependency avoidance creates a clear niche that is unlikely to conflict with other skills. | 3 / 3 |
Total | 8 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable conceptual framework for Android modularization decisions but falls short on actionability — the core weakness. It reads more like a decision-making guide than an executable skill, lacking concrete build.gradle.kts configurations, dependency graph examples, or actual code showing how to implement the splits it describes. The workflow is logically sequenced but would benefit from validation checkpoints and concrete verification steps.
Suggestions
Add concrete, executable code examples: show actual build.gradle.kts snippets demonstrating api vs implementation dependencies, a sample module graph configuration, and a before/after of a feature module split.
Include a validation step in the workflow, such as running `./gradlew buildHealth` or a custom script to verify no cyclic dependencies exist after restructuring.
Replace or supplement the fictional example project paths with inline code showing what the module structure and dependency declarations actually look like (e.g., a settings.gradle.kts include block and corresponding module build files).
Add a concrete example of detecting and fixing a cyclic dependency, showing the before state, the diagnostic command/output, and the after state.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably efficient and doesn't over-explain basic concepts, but some sections like Guardrails and Anti-Patterns contain somewhat generic advice that Claude would already know (e.g., 'prefer official guidance over custom conventions', 'do not mix architectural cleanup with product behavior changes'). Could be tightened. | 2 / 3 |
Actionability | The skill provides high-level workflow steps and principles but lacks concrete, executable guidance. There are no code examples showing actual module configurations (e.g., build.gradle.kts snippets for api vs implementation), no specific dependency declarations, and the 'examples' section references fictional project paths and scripts without showing actual outputs or configurations. | 1 / 3 |
Workflow Clarity | The workflow has a clear 5-step sequence that logically progresses from mapping to splitting to handoff. However, it lacks validation checkpoints — there's no explicit step to verify the new module graph is acyclic, no feedback loop for when splits introduce new issues, and no concrete verification commands beyond the example Gradle commands. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and mentions handoff skills (android-gradle-build-logic, android-architecture-clean). However, the references to example directories and scripts appear to be fictional or at least unverified, and the official references are just a flat list without context about when to consult each one. | 2 / 3 |
Total | 7 / 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 |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 10 / 11 Passed | |
c5bf673
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.