TypeScript Code One Task Group

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

Implement one bucket of TypeScript tasks from a plan’s task group end to end: capture a single pre-change quality baseline, run iru-typescript-code-one-task once per task (in parallel when the group allows it), then validate the entire bucket once — license headers, TSDoc, scoped tests, an 80% coverage check, a full-suite run, and a code-quality regression check.

Purpose

iru-typescript-code-one-task-group is the npm/TypeScript counterpart to iru-java-code-one-task-group, carrying the same cost-cutting shape into TypeScript projects: it validates a whole bucket once instead of once per task. Step 1 detects the project’s flavor (hilla-frontend / react-native / ionic / angular / react / library), test runner (Vitest, Jest, or the Angular CLI builder), and package manager (npm/pnpm/yarn) once, then captures a pre-change quality baseline covering every file the bucket’s tasks are expected to touch. Step 2 implements each task via iru-typescript-code-one-task — concurrently, in a single batch of Agent calls, when the plan marks the group Parallelizable: yes; one at a time otherwise. iru-typescript-code-one-task itself checks off each task’s box in implementation_plan.md the moment that task finishes, with a "group validation pending" note — this skill 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 before group-wide validation runs. Once every non-blocked task has landed, Step 3 validates the whole bucket in one pass: license headers, TSDoc, the affected test files, coverage, the full suite, and a quality-regression check against its one baseline. 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.

When the bucket added or changed UI in a react/angular/ionic/hilla-frontend project, a UI stage (Step 3.7) follows the quality check, per the catalog’s UI contract (see Building user interfaces). It takes the repository-wide .integration-test.lock, checks the Playwright web-server ports, runs iru-typescript-test with the ui selector scoped to the bucket’s specs, verifies the screenshot matrix in .ui-screenshots/ (every changed component/screen state x the .ui-quality.yml directions x themes) and applies the accessibility level (enforce fails, report lists, off is noted). A project without Playwright, a busy port, a missing browser or a lock timeout makes the stage unverified, never silently passed; it never scaffolds Playwright or installs browsers.

React Native is its own key: when Step 1 classifies the project as react-native (Expo or bare CLI/Metro) and iru-react-native-code-one-task-group is installed, the whole bucket is handed to that skill and this one stops, because it owns the native builds, Expo prebuild check, and device e2e stage this skill does not run. Without it, this skill continues and states in its Step 5 report that those stages were not run.

When .ui-quality.yml says accessibility: none (the user opted out of accessibility support entirely), the accessibility rules are not applied and the accessibility checks (axe, ATF/semantics audit, performAccessibilityAudit(), Axe.Windows, a11y lint rules, TUI asserted checks) are not run or required; they are reported as "accessibility: opted out" in the group report — never "unverified" and never a failure. off differs: the rules still apply when writing code, only the automated checks are not run. 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.

Purpose group

TypeScript Development Tooling

Plugin

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

Invocation

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

Inputs

Argument Required Description Default

Bucket text

Yes

Every TypeScript-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-typescript-code-one-task.

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

  • Tests achieving at least 80% line and branch coverage for the bucket’s changed/new files, verified against the real coverage report.

  • 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-typescript-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 buckets: screenshots under .ui-screenshots/<kind>/<Id>/ from the scoped ui run, and per UI task a progress-note suffix such as the captured matrix and the accessibility result at the .ui-quality.yml level, or "UI unverified" with the reason. The .integration-test.lock/ directory is held only during that stage and always released.

  • For a React Native bucket with iru-react-native-code-one-task-group installed: that skill’s Step 5 report relayed as this skill’s own, noting the hand-off.

  • A summary handed back to the caller (iru-code-one-task-group): per task, files touched, tests added/updated, coverage achieved, code-quality outcome, for UI tasks the decomposition tree, the screenshot-matrix result (captured or missing cells) and the accessibility result, or the UI stage’s unverified reason, and any task that stopped on a blocker.

Execution flow

flowchart TD A[Start /iru-typescript-code-one-task-group] --> B["Step 1: detect flavor, test runner\nand package manager once;\ncapture pre-change quality baseline\n(iru-typescript-code-quality, via iru-gate-runner)"] B --> RN{"react-native flavor and\niru-react-native-code-one-task-group\ninstalled?"} RN -- yes --> RN2["Hand whole bucket to it;\nrelay its Step 5 report; stop"] RN -- no --> C{Bucket Parallelizable?} C -- yes --> D["Step 2: invoke typescript-code-one-task\nfor every task concurrently"] C -- no --> E["Step 2: invoke typescript-code-one-task\nfor each task, one at a time"] D --> F["Confirm/backfill each task's box\n(set by typescript-code-one-task itself); notify user"] E --> F F --> G["Step 3: validate the whole bucket once —\nlicense headers, TSDoc, scoped tests,\ncoverage, full suite, quality vs. baseline"] G -- failure traced to a task --> H["Fix that task's implementation;\nre-run the affected check(s)"] H --> G G -- clean --> U{"UI added or changed?"} U -- no --> I U -- yes --> U1["Step 3.7: UI stage: take .integration-test.lock,\nrun iru-typescript-test ui (scoped), check capture matrix\nand accessibility, release lock"] U1 -- gap or enforce failure --> H U1 --> 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

  • TypeScript 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.

  • React Native Code One Task Group — Step 1, hands the entire bucket over for react-native projects when that skill is installed; this skill then stops.

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:

  • TypeScript Code Quality — Step 1 (pre-change baseline for the bucket) and Step 3.6 (final regression check against that baseline).

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

  • TypeScript TSDoc — Step 3.2, TSDoc for every exported symbol the bucket touched.

  • TypeScript Test — Step 3.3, scoped tests for every file the bucket affected, plus the Step 3.5 full-suite run (npm test / pnpm test / yarn test) and the Step 3.7 UI stage’s ui run (scoped Playwright specs, lock held).

  • TypeScript Coverage — Step 3.4, coverage for every changed/new file in the bucket.

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.