android-state-management
Model screen state, events, reducers, and side effects for Android UIs with predictable lifecycle-aware ownership.
47
35%
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 ./skills/android-state-management/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 communicates an architectural modeling concern for Android UI state management but relies heavily on technical jargon without concrete actions or explicit trigger guidance. It lacks a 'Use when...' clause, which is critical for skill selection, and the capabilities described are abstract concepts rather than specific tasks Claude would perform.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about Android state management, MVI architecture, ViewModel patterns, or building predictable UI state flows.'
Replace abstract concepts with concrete actions, e.g., 'Generates ViewModel classes with sealed state/event classes, reducer functions, and coroutine-based side effects for Android Compose or View-based UIs.'
Include natural trigger terms users would actually say, such as 'ViewModel', 'MVI', 'state management', 'Compose', 'UI state', 'unidirectional data flow'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Android UIs) and lists several concepts (screen state, events, reducers, side effects), but these are architectural concepts rather than concrete user-facing actions. It doesn't describe what specific tasks the skill performs (e.g., 'generate ViewModel classes', 'create state sealed classes'). | 2 / 3 |
Completeness | Describes what it does (model screen state, events, reducers, side effects) 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 somewhat vague, warranting a 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'Android', 'screen state', 'reducers', 'side effects', and 'lifecycle-aware', but these are more technical/architectural jargon than natural user language. Missing common terms users might say like 'ViewModel', 'MVI', 'UDF', 'Compose state', 'UI architecture', or 'state management'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'Android UIs' with 'reducers' and 'lifecycle-aware ownership' narrows the scope somewhat, but it could overlap with general Android development skills, Compose UI skills, or architecture pattern skills. The lack of specific framework or pattern names (MVI, UDF) reduces distinctiveness. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
37%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a reasonable structural framework for Android state management with useful Kotlin code snippets demonstrating immutable state, event separation, and state reduction. However, the workflow steps are too abstract to be actionable, lacking concrete validation checkpoints and feedback loops critical for state management correctness. The skill would benefit from a more complete end-to-end example and specific verification steps rather than high-level platitudes.
Suggestions
Replace the abstract workflow steps with concrete, sequenced actions (e.g., '1. Define sealed class for UI state → 2. Create ViewModel with StateFlow → 3. Write unit test verifying state transitions → 4. Verify configuration change survival with test').
Add explicit validation checkpoints to the workflow, such as 'Run unit tests to verify state survives configuration changes' or 'Check that SharedFlow events are not replayed after rotation'.
Provide a complete end-to-end ViewModel example that ties together the three remediation snippets, showing how state, events, and reducers work together in a single cohesive class.
Trim the guardrails and anti-patterns to only non-obvious guidance, and make the example commands more actionable by explaining what the referenced projects contain or providing inline test examples.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some sections that are somewhat generic (e.g., the workflow steps are high-level platitudes like 'Confirm the user-visible journey' that don't add much value). The guardrails and anti-patterns sections contain useful but somewhat obvious guidance that an experienced Android developer (or Claude) would already know. | 2 / 3 |
Actionability | The Kotlin code snippets in the Remediation Examples section are concrete and executable, showing immutable state, event separation, and state reduction. However, the workflow steps are vague ('Confirm the user-visible journey'), the example commands reference project directories that may not exist, and there's no complete end-to-end implementation showing how these pieces connect (e.g., a full ViewModel with event handling). | 2 / 3 |
Workflow Clarity | The workflow steps are abstract and lack concrete validation checkpoints. Steps like 'Confirm the user-visible journey' and 'Validate accessibility, configuration changes' are vague directives without specific commands or tools. For a skill involving state management with potential for subtle bugs (lost events, configuration change crashes), there are no explicit validation or verification steps with feedback loops. | 1 / 3 |
Progressive Disclosure | The skill has clear section headers and references handoff skills (android-coroutines-flow, android-ui-states-validation) and official references. However, the content is somewhat monolithic—the guardrails, anti-patterns, and remediation examples could benefit from better organization, and the references to example projects lack context about what those projects contain or how to navigate them. | 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 | |
- Repository
- krutikJain/android-agent-skills
- Commit
c5bf673
- 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.