Android Code One Task Group

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Implement one bucket of Android/Kotlin tasks from a plan’s task group end to end: detect which Gradle module(s) (lib/app) the bucket touches, capture a single pre-change quality baseline, run iru-android-code-one-task once per task (in parallel when the group allows it), then validate the entire bucket once per touched module — license headers, KDoc, scoped unit tests, an 80% unit-test line-coverage bar, a full-suite run, and a code-quality regression check — plus, when the bucket touched UI, a UI stage (Robolectric/Roborazzi screenshots and accessibility checks).

Purpose

iru-android-code-one-task-group is the Gradle/Kotlin counterpart to iru-java-code-one-task-group and iru-typescript-code-one-task-group: it consolidates per-task validation into a single pass per bucket, scoped per Gradle module the bucket actually touched, since an Android repository may span both a lib and an app module. It captures one pre-change quality baseline covering every class the bucket’s tasks are expected to touch, then implements each task via iru-android-code-one-task (concurrently, in a single batch of Agent calls routed through iru-isolated-skill-executor, when the plan marks the group Parallelizable: yes; one at a time otherwise). iru-android-code-one-task itself checks off each task’s box in implementation_plan.md the moment that task finishes cleanly, with a "group validation pending" note — this skill just re-reads the file as each task’s agent reports back to confirm the box landed, backfilling it only if a rare concurrent-write race clobbered it, and notifies the user that implementation landed. Once every non-blocked task has landed, it validates the whole bucket in one pass, per touched module: license headers, KDoc (via iru-android-dokka), the affected unit-test classes, unit-test line coverage against an 80% bar (instrumented coverage is reported for information only and never counted toward it), a full ./gradlew test run, and a quality-regression check against its one baseline. When the bucket added or changed a screen, component or list, a UI stage (Step 3.7) also reads .ui-quality.yml, runs the ui selector of iru-android-test, checks that .ui-screenshots/ holds a capture for every state × direction × theme, and applies the accessibility level (enforce/report/off/none; none opts out entirely and is reported as "accessibility: opted out"); an on-device flow stage with no attached device or emulator is reported unverified. A failure traced to a specific task sends that task back for a fix and a re-run of the affected checks, rather than re-validating the whole bucket. The UI contract is described in Building user interfaces. When .ui-quality.yml is missing in a repository that already has UI code, it doesn’t assume enforce: before the first UI task it asks once, pre-selected from iru-explore’s `Accessibility: line, and writes the file.

Kotlin Multiplatform projects are out of scope: when the Kotlin Multiplatform plugin is applied anywhere in the build (a KMP app’s Android host module included), the skill stops and hands the request to KMP Code One Task Group instead.

Purpose group

Android Development Tooling

Plugin

Shipped by the iru-android plugin of the ai-catalog marketplace (install with /plugin install iru-android@ai-catalog; see Plugins).

Invocation

/iru-android-code-one-task-group <bucket text>

Inputs

Argument Required Description Default

Bucket text

Yes

Every Android-tagged task/sub-task in the bucket, each with its own text, plus the group’s Parallelizable verdict and any relevant "Current code state" context.

None — this skill is always invoked with a specific bucket’s text, by iru-code-one-task-group.

Outputs

  • Source and test files created/modified per task, via iru-android-code-one-task, scoped to the lib and/or app module each task touches.

  • License headers and KDoc kept current across every file/class the bucket touched, checked once for the whole bucket rather than once per task.

  • Unit tests achieving at least 80% line coverage (unit-test only) for the bucket’s changed/new classes, per module, verified against the real JaCoCo/Kover report; any already-on-disk instrumented coverage is reported for information only.

  • implementation_plan.md with each task’s (and sub-task’s) checkbox checked and a progress note — first an "implemented, group validation pending" note written by iru-android-code-one-task itself as each task lands (backfilled here only if a rare concurrent-write race dropped it), then replaced with the final coverage/quality outcome once bucket-wide validation passes.

  • User-facing notifications at both phases: per task as its implementation lands, and once when group validation completes.

  • For UI tasks, the UI stage outcome: screenshot counts per kind under .ui-screenshots/, missing captures, accessibility violations and the level applied, with the result appended to the task’s note in implementation_plan.md.

  • A summary handed back to the caller (iru-code-one-task-group): per task, its module, files touched, tests added/updated, unit-test coverage achieved, code-quality outcome, which of ./gradlew test/testDebugUnitTest actually ran, and any task that stopped on a blocker.

Execution flow

flowchart TD A[Start /iru-android-code-one-task-group] --> B["Step 1: detect touched module(s)\n(lib/app); capture one pre-change\nquality baseline (android-code-quality,\nvia iru-gate-runner)"] A -. "KMP plugin applied" .-> KMP["Stop: hand off to iru-kmp-code-one-task-group"] B --> C{Bucket Parallelizable?} C -- yes --> D["Step 2: invoke android-code-one-task\nfor every task concurrently\n(via iru-isolated-skill-executor)"] C -- no --> E["Step 2: invoke android-code-one-task\nfor each task, one at a time"] D --> F["Confirm/backfill each task's box\n(set by android-code-one-task itself); notify user"] E --> F F --> G["Step 3: validate the whole bucket once,\nper touched module — license headers,\nKDoc, scoped unit tests, 80% unit-test\ncoverage, full suite, quality vs. baseline,\nUI stage when UI was touched\n(ui tests, captures, accessibility)"] G -- failure traced to a task --> H["Fix that task's implementation;\nre-run the affected check(s)"] H --> G G -- clean --> I["Step 4: finalize each task's note\nwith final outcome; notify user"] I --> J["Step 5: report the bucket's\noutcome to the caller"]

Dependencies

Invokes

  • Android Code One Task — Step 2, once per task in the bucket (concurrently or sequentially per the group’s Parallelizable verdict), via the iru-isolated-skill-executor agent — that skill implements exactly what the task specifies, writes/updates its tests, and checks off its own checkbox in implementation_plan.md with a "group validation pending" note before reporting back.

Each of the following is invoked via the iru-gate-runner agent rather than directly, so verbose report output stays out of this skill’s own context:

  • Android Code Quality — Step 1 (pre-change baseline for the bucket) and Step 3.6 (final regression check against that baseline), scoped per touched module.

  • Check License — Step 3.1, license headers for every file the bucket touched.

  • Android Dokka — Step 3.2, KDoc for every class the bucket touched.

  • Android Test — Step 3.3, scoped unit tests for every class the bucket affected, per touched module.

  • Android Coverage — Step 3.4, unit-test line/branch coverage for every changed/new class, per touched module.

  • Android Test with its ui selector — Step 3.7 (only when the bucket touched UI), the Robolectric/Roborazzi JVM UI tests and, when a device is attached, the on-device flow tests.

  • Step 3.5 runs the plan’s literal ./gradlew test (or testDebugUnitTest as a lighter-weight substitute) directly for full-suite regression coverage — not a catalog skill.

It stops and redirects Kotlin Multiplatform projects to KMP Code One Task Group (a hand-off, not an invocation).

Invoked by

Related agents

  • iru-isolated-skill-executor — spawned once per task in the bucket (Step 2), potentially many at once when the group is parallelizable, so each task’s own implementation transcript doesn’t accumulate in this skill’s context.

  • iru-gate-runner — spawned for the baseline capture (Step 1) and every validation check (Step 3), keeping full reports out of this skill’s context.

Source

SKILL.md on GitHub — the file this page was generated from.