React Native Code One Task Group
| This documentation was generated with the assistance of AI. Please report any inaccuracies. |
Implement one bucket of React Native tasks from a plan’s task group end to end: capture a single pre-change quality
baseline, run iru-react-native-code-one-task once per task (in parallel when allowed), then validate the entire
bucket once — headers, TSDoc, Jest, an 80% unit-only coverage gate, type-check, native stages, and a lock-guarded
device e2e run.
Purpose
iru-react-native-code-one-task-group is built on the same TypeScript gate skills as
iru-typescript-code-one-task-group, each run through an iru-gate-runner agent so no raw report lands in its
context, and adds four React Native-specific concerns. Native code has its own gates and the toolchain decides who
owns it: for metro apps android/ and ios/ are committed source, so Step 3.7-3.8 build the side the bucket
touched; for expo apps they are generated, so an edit there is a defect and Step 3.9 validates config-plugin
changes by running expo prebuild in a throwaway copy. The coverage gate counts Jest unit tests only, since e2e
flows and native tests produce no coverage of the measured TypeScript. tsc --noEmit is its own gate, because Jest
presets strip types without checking them. The e2e stage needs a device, a build, and Metro, so it runs last and
only while holding the repository-wide .integration-test.lock (acquired in Step 3.10a, released in 3.10b on every
exit path; stale after 60 minutes, wait timeout around 45 minutes).
Step 1 detects the profile once and captures a baseline (plus an Android Lint baseline when metro tasks touch
android/). Step 2 implements tasks, but tasks that edit the same navigator/layout file or native registration point
run sequentially even in a parallelizable group. Step 3 runs license headers, TSDoc, scoped tests, coverage, the
full suite, quality diffed against baseline, the Android, iOS, and Expo native stages as applicable, then e2e. Steps
4-5 finalize the plan notes and report; any unverified stage is named with its reason rather than read as a pass.
When the bucket touched UI, the device run of Step 3.10 doubles as the UI run (Maestro gallery capture flows under .maestro/ui/ and flow captures, or Detox, written into .ui-screenshots/), and a new Step 3.11 checks the evidence: every added/changed screen and component must have a capture for each declared state × .ui-quality.yml direction × theme on the platform that ran, and eslint-plugin-react-native-a11y findings from the lint gate are applied at the configured accessibility level (enforce fails the group, report lists them). No device makes the captures unverified, never passed. See Building user interfaces. With accessibility: none in .ui-quality.yml (opted out entirely), the accessibility rules and checks are neither applied nor required and are reported as "accessibility: opted out" in the group report, never unverified or failed; off still applies the rules but skips the automated checks. 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.
Plugin
Shipped by the iru-react-native plugin of the ai-catalog marketplace (install with /plugin install iru-react-native@ai-catalog; see Plugins).
Inputs
| Argument | Required | Description | Default |
|---|---|---|---|
Bucket text |
Yes |
Every |
None — invoked with a specific bucket’s text by |
Outputs
-
Source, native, and config files plus tests per task, via
iru-react-native-code-one-task. -
License headers and TSDoc kept current for every file the bucket touched, checked once for the whole bucket.
-
Unit-only coverage of at least 80% line and branch for changed/new TS/TSX files, with any device-only file recorded as an accepted exception.
-
A type-check (
tsc --noEmit), lint and format result compared to the single pre-change baseline. -
Android, iOS, and Expo native-config stage results where applicable, each passed, failed-and-fixed, skipped as not applicable, or unverified with a reason.
-
An e2e (Maestro/Detox, optionally XCTest) result run under the shared lock, or unverified with the cause.
-
For UI buckets (Step 3.11): captures found vs expected per screen/component, malformed names, missing capture infrastructure (UI gallery,
.maestro/ui/flows), andreact-native-a11y/*violations (count and rule ids) at the.ui-quality.ymllevel, or "UI captures unverified" with the reason. -
implementation_plan.mdwith each task’s checkbox finalized with unit-only coverage, native stages, and e2e results reported separately; blocked tasks stay unchecked with their blocker note. -
A report to the caller covering profile, per-task details, coverage exceptions, type-check results, native stages, e2e result, lock behavior, and which tasks need a new native build or are not OTA-compatible.
Execution flow
Dependencies
Invokes
-
React Native Code One Task — Step 2, once per task in the bucket (concurrently or sequentially per the
Parallelizableverdict, with conflicting registration-point tasks forced sequential), via theiru-isolated-skill-executoragent.
Each of the following is invoked via the iru-gate-runner agent rather than
directly:
-
TypeScript Code Quality — Step 1 (pre-change baseline) and Step 3.6 (ESLint,
tsc --noEmit, Prettier diffed against it). -
Check License — Step 3.1, license headers for every file the bucket touched.
-
TypeScript TSDoc — Step 3.2, TSDoc for exported TS/TSX symbols.
-
TypeScript Test — Step 3.3 (scoped Jest tests), Step 3.5 (full unit suite), and Step 3.10 (
e2eselector withlock: held). -
TypeScript Coverage — Step 3.4, unit-only coverage gate.
-
Android Code Quality and Android Test — Steps 1 and 3.7, for a metro app’s
android/side, only when they can target theandroid/Gradle root; otherwise plain./gradlewcommands run through the same agent.
Invoked by
-
Code One Task Group — Step 2, bucket for key react-native.
-
TypeScript Code One Task Group — Step 1, hands the whole bucket over when the detected flavor is React Native and this skill is installed, and relays its report.
Related agents
-
iru-isolated-skill-executor— spawned once per task (Step 2), many at once when parallelizable. -
iru-gate-runner— spawned for the baseline (Step 1) and every validation, native-build, Expo-check, and e2e stage (Step 3), keeping reports out of this skill’s context.
Source
SKILL.md on GitHub — the file this page was generated from.