Migrate Android RxJava code to Kotlin coroutines and Flow with safe lifecycle-aware replacements.
71
64%
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-rxjava-to-coroutines-migration/SKILL.mdQuality
Discovery
72%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 clearly identifies a specific migration task (RxJava to Kotlin coroutines/Flow) with good domain-specific trigger terms that developers would naturally use. Its main weaknesses are the lack of an explicit 'Use when...' clause and the absence of more granular concrete actions (e.g., converting specific RxJava types). Adding explicit trigger guidance and enumerating specific migration patterns would strengthen it.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to replace RxJava with coroutines, convert Observables/Singles/Completables to Flow or suspend functions, or remove RxJava dependencies from an Android project.'
List more specific concrete actions such as 'converts Singles to suspend functions, replaces Observables with StateFlow/SharedFlow, migrates Disposable management to structured concurrency' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Android RxJava to Kotlin coroutines/Flow migration) and the general action (migrate with safe lifecycle-aware replacements), but doesn't list multiple specific concrete actions like converting Singles to suspend functions, replacing Observables with Flow, handling Disposables, etc. | 2 / 3 |
Completeness | Clearly answers 'what' (migrate RxJava to coroutines/Flow with lifecycle-aware replacements) but lacks an explicit 'Use when...' clause or equivalent trigger guidance, which caps this at 2 per the rubric. | 2 / 3 |
Trigger Term Quality | Includes strong natural keywords a user would say: 'RxJava', 'Kotlin coroutines', 'Flow', 'migrate', 'Android', 'lifecycle-aware'. These are the exact terms developers would use when seeking this kind of help. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche combining Android, RxJava-to-coroutines migration, and lifecycle awareness. Unlikely to conflict with general Kotlin skills, general Android skills, or other migration tools. | 3 / 3 |
Total | 10 / 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 well-structured migration skill that correctly identifies the key concerns (hot vs cold, lifecycle ownership, staged migration) and uses progressive disclosure effectively. Its main weaknesses are the lack of concrete before/after code examples showing actual RxJava-to-coroutines transformations and the absence of explicit validation checkpoints in the multi-step workflow, which is critical for behavior-preserving refactoring.
Suggestions
Add at least one concrete before/after code example showing a common migration (e.g., Single<User> → suspend fun getUser(), or Observable with CompositeDisposable → Flow with repeatOnLifecycle) to improve actionability.
Insert explicit validation checkpoints in the workflow, such as 'Run tests after repository migration before proceeding to ViewModel layer' to ensure staged verification is enforced.
Consolidate the 'Review Focus' section into the existing Guardrails or Workflow sections to reduce redundancy and improve conciseness.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably efficient but includes some sections that could be tightened. The 'When To Use' section has redundant bullet points, and the 'Review Focus' section largely restates what's already covered in Guardrails and Workflow. However, it doesn't over-explain basic concepts. | 2 / 3 |
Actionability | The workflow provides a clear sequence of steps and the examples reference concrete scripts, but there are no actual code snippets showing before/after migration patterns (e.g., Single→suspend, Observable→Flow). The guidance is specific in intent but lacks executable, copy-paste-ready code examples that would make it fully actionable. | 2 / 3 |
Workflow Clarity | The 5-step workflow is clearly sequenced and logically ordered (inventory → classify → replace bottom-up → rewrite infrastructure → leave checklist). However, it lacks explicit validation checkpoints between steps—there's no 'verify tests pass after repository migration before moving to UI layer' or similar feedback loops, which is important for a staged migration that could break behavior. | 2 / 3 |
Progressive Disclosure | The skill appropriately references external files (references/patterns.md, references/scenarios.md) for detailed content, keeps the main file as an overview, and signals handoff skills clearly. References are one level deep and well-signaled with clear descriptions of what each contains. | 3 / 3 |
Total | 9 / 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.