Swift Code One Task Group

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

Implement one bucket of Swift tasks from a plan’s task group end to end: capture a single pre-change quality baseline, run iru-swift-code-one-task once per task (in parallel when the group allows it), then validate the entire bucket once — license headers, DocC, a scoped test run, 80% line coverage, a full-suite run, and a code-quality regression check, with xcodebuild test runs serialized behind a repository-wide simulator lock.

Purpose

iru-swift-code-one-task-group is the Swift Package Manager / Apple-app counterpart to iru-java-code-one-task-group/iru-typescript-code-one-task-group/iru-android-code-one-task-group, built on iru-swift-code-quality, iru-swift-test, iru-swift-coverage, and iru-swift-docc. It captures one pre-change quality baseline covering every file the bucket’s tasks are expected to touch, then implements each task via iru-swift-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-swift-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 before group-wide validation runs. Because an app-target test/coverage/full-suite run boots and drives an iOS/tvOS/watchOS Simulator, and only one such run can safely use a given destination at a time, every xcodebuild test invocation is serialized behind a repository-wide mkdir-based lock (.simulator-test.lock) so two parallel task groups never collide; a Swift Package’s swift test needs no simulator and never takes this lock. For an app it resolves the bucket’s scheme(s) once — with iru-setup-apple-app’s per-platform schemes (<AppName>-iOS`, -macOS, -watchOS, -visionOS) the schemes of the platforms whose Targets/<Platform>/ files the bucket touches, plus every platform scheme for the full-suite run — and each scheme’s destination (platform=macOS, or a simulator destination always pinned with OS=<runtime> because device names repeat across runtimes), then makes one gate call per scheme. A platform with no installed simulator runtime (typically visionOS) is compile-checked with a generic/platform=visionOS Simulator destination and reported "unverified (no visionOS simulator runtime installed)" — a runtime is never downloaded. Coverage for files under a local Packages/Core package goes in a separate package-path: Packages/Core call (measured with swift test
llvm-cov, no simulator or lock), since the app scheme’s xccov report can’t see a statically linked local package; that is where the 80% bar applies, while app-target UI code is reported "not measured". A macOS desktop app bucket needs no simulator runtime, but its XCUITest run drives the real desktop session through the same lock; those UI tests need the test runner’s Accessibility/automation permission and an unlocked, logged-in desktop, and without them the UI-test stage is reported unverified, not passed. A command-line tool (a package whose Package.swift declares an .executableTarget depending on ArgumentParser, the iru-setup-swift-cli layout) is package-kind throughout: Step 1 records its executable target <Bin>, logic library <Bin>Kit, in-process test target <Bin>KitTests and end-to-end target <Bin>CLITests; it needs no simulator, lock or containers; the scoped and full-suite runs include <Bin>CLITests; and the 80% bar is measured on the Sources/<Bin>Kit/ files (plus touched Sources/<Bin>/ files) from the full suite with every test binary, so llvm-cov sees the profiles of the binaries the CLI tests spawn. On a non-macOS host every app stage is reported "unverified (needs macOS)". 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 a screen, component or list (never for a command-line tool), a UI stage (Step 3.7) follows the full-suite run under the same lock, per the catalog’s UI contract (see Building user interfaces): it reads .ui-quality.yml, runs iru-swift-test with the ui selector scoped to the bucket’s component and UI-test suites (lock: held, so it never clears .ui-screenshots/), checks that every changed screen/component has a capture for each visual state x configured direction x theme, and applies the accessibility level (enforce fails the group, report only lists, off is noted; none means the user opted out, so the accessibility rules and checks are not applied or required). A missing simulator runtime, desktop-session permission or lock timeout makes the stage unverified, never skipped silently. 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

Swift Development Tooling

Plugin

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

Invocation

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

Inputs

Argument Required Description Default

Bucket text

Yes

Every Swift-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-swift-code-one-task.

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

  • Tests achieving at least 80% unit-test line coverage for the bucket’s changed/new files (branch coverage is unavailable for Swift and is never part of the bar).

  • For UI buckets: screenshots under .ui-screenshots/<kind>/<Id>/ (gitignored, produced by the scoped ui run) and a UI-stage outcome per task: captures per state x direction x theme and the accessibility result at the .ui-quality.yml level, or "UI stage unverified" with the reason.

  • A transient .simulator-test.lock/ directory (with an owner file) held only while an app-kind bucket’s xcodebuild test runs are in flight, added to the repository’s root .gitignore if missing, and always released before this skill finishes.

  • 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-swift-code-one-task itself as each task lands, 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.

  • A summary handed back to the caller (iru-code-one-task-group): per task, target, files touched, tests added/updated, coverage achieved, code-quality outcome, any unverified stage (no full Xcode install, lock wait timeout, a platform scheme with no simulator runtime such as visionOS), how the simulator lock behaved, the UI stage outcome when it ran (screenshot counts per kind, missing matrix cells, accessibility issues by rule id, or why it was unverified), and any task that stopped on a blocker.

Execution flow

flowchart TD A[Start /iru-swift-code-one-task-group] --> B["Step 1: detect project shape (package/app),\nper-platform scheme to OS-pinned destination map\n(no runtime: unverified + generic build),\ntouched target(s); capture pre-change quality baseline\n(iru-swift-code-quality, via iru-gate-runner)"] B --> C{Bucket Parallelizable?} C -- yes --> D["Step 2: invoke swift-code-one-task\nfor every task concurrently\n(via iru-isolated-skill-executor)"] C -- no --> E["Step 2: invoke swift-code-one-task\nfor each task, one at a time"] D --> F["Confirm/backfill each task's box\n(set by swift-code-one-task itself); notify user"] E --> F F --> G["Step 3.1-3.2: license headers, DocC\n(via iru-gate-runner)"] G --> H{"App-kind bucket?"} H -- yes --> I["Step 3.3: acquire simulator lock\n(mkdir .simulator-test.lock)"] H -- no --> K["Step 3.4-3.6: scoped tests, coverage,\nfull suite, one call per scheme;\nPackages/Core coverage via package-path\n(via iru-gate-runner)"] I -- HELD --> I2["Wait, poll ~30s;\nstale lock (&gt;60min) broken;\nwait timeout (~45min) reported unverified"] I2 --> I I -- ACQUIRED --> K K -- failure traced to a task --> L["Fix that task's implementation;\nre-run the affected check(s)"] L --> K K -- clean --> U{"UI screen/component/list\nadded or changed? (not a CLI)"} U -- yes --> U1["Step 3.7: UI stage via iru-swift-test ui\n(scoped, lock held); check capture matrix and\naccessibility at the .ui-quality.yml level"] U1 -- gap or enforce failure --> L U1 --> M U -- no --> M{"App-kind bucket?"} M -- yes --> N["Step 3.8: release simulator lock"] M -- no --> O["Step 3.9: code quality regression\ncheck vs. baseline (via iru-gate-runner)"] N --> O O -- new issue --> L O -- clean --> P["Step 4: finalize each task's note\nwith final outcome; notify user"] P --> Q["Step 5: report the bucket's\noutcome to the caller"]

Dependencies

Invokes

  • Swift Code One Task — Step 2, once per task in the bucket, via the iru-isolated-skill-executor agent when the bucket is parallelizable (all tasks at once) or directly, one at a time, otherwise — that skill implements exactly what the task specifies, writes/updates its tests, compile-checks the target, 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:

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

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

  • Swift DocC — Step 3.2, DocC documentation for every type the bucket touched.

  • Swift Test — Step 3.4 (and the ui run of Step 3.7 for UI buckets, with lock: held), a scoped test run for every test the bucket affected, one call per in-scope scheme with its kind:/scheme:/destination: lines.

  • Swift Coverage — Step 3.5, line coverage for every changed/new file/type in the bucket, one call per scheme plus a separate package-path: Packages/Core call for local-package files.

Step 3.6’s full-suite run (swift test for a package, xcodebuild test once per platform scheme for an app, under the Step 3.3 simulator lock) is run directly by iru-gate-runner rather than through a named skill, so it has no dedicated skill xref.

Invoked by

Related agents

  • iru-isolated-skill-executor — spawned once per task in the bucket (Step 2) 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.