◆ Sparround

Practical skills for Android

Three kinds of work in Android projects most deserve to become skills:

1. Recurring review checklists — Compose, coroutines, resource leaks. The same questions in every PR.

2. Multi-step creation procedures — a new module, a new screen, a new test suite. A step always gets forgotten.

3. Release preparation — version, ProGuard, permissions, debug leftovers.

This topic has a working example of each. Adapt them to your project's real rules — they are not meant to be copied verbatim.

markdown
---
description: Reviews coroutine and Flow usage — scope choice, dispatcher, exception handling and collection in Compose. Use when the user asks for a review of coroutines, Flow, suspend functions or async code.
allowed-tools: Read, Grep, Glob
paths:
  - "**/*.kt"
---

# Coroutine / Flow review

!`git diff --name-only main -- '*.kt'`

Read the files above that contain `suspend`, `launch`, `Flow` or
`collect`, and check:

1. **Scope** — is `GlobalScope` used anywhere? It should be
   `viewModelScope` in a ViewModel, and `rememberCoroutineScope`
   or `LaunchedEffect` in a Composable.
2. **Dispatcher** — is IO work on `Dispatchers.IO`?
   Is the dispatcher hardcoded or injected?
   (It should be injected, for testability.)
3. **Exceptions** — is an exception thrown inside `launch` caught?
   Is there a `try/catch` or a `CoroutineExceptionHandler`?
4. **Collection in Compose** — is `collectAsStateWithLifecycle`
   used, or plain `collectAsState`?
5. **Cancellation** — do long loops check `ensureActive()` or
   `isActive`?

Output: `file:line` plus a short explanation and a suggestion for
each finding. Do not modify files.

A coroutine review skill. Thanks to `paths` it auto-loads only when Kotlin files are in play.

markdown
---
description: Writes a UI test for an existing Composable — createComposeRule, semantics finders and assertions. Use when the user wants a test written for Compose.
argument-hint: [name of the Composable]
arguments: composable
---

# Compose UI test: $composable

## Existing test examples

!`find . -path '*/androidTest/*' -name '*Test.kt' | head -3`

## Steps

1. Find the `$composable` function and read its parameters.
2. Read one of the existing tests above and follow the project's
   test style (naming, setup, fakes).
3. Write the test under `androidTest`:
   - `createComposeRule()` when no Activity is needed
   - `createAndroidComposeRule<T>()` when one is
4. Cover: the initial state, a user action, the result, and the
   empty/error state if there is one.
5. Run `./gradlew :app:compileDebugAndroidTestKotlin`.

Note: finding by text (`onNodeWithText`) breaks when localisation
changes. Prefer `testTag`, adding `Modifier.testTag(...)` to the
Composable where needed.

A test-writing skill. Making it read an existing test as the pattern is the most reliable way to get project-consistent output.

A pattern recurs in these examples: make the agent read an existing file as the template. That is more reliable than writing conventions into the skill, because the skill adapts as the code changes while documentation goes stale.

📚 Sources and documentation