Windows Code One Task Group
| This documentation was generated with the assistance of AI. Please report any inaccuracies. |
Implement one bucket of Windows desktop app tasks from a plan’s task group end to end: detect the project shape and
the bucket’s validation scope once, capture a single pre-change analyzer baseline, run iru-windows-code-one-task once
per task (in parallel when the group allows it), then validate the entire bucket once — cheapest checks first, the
FlaUI desktop UI stage last, only on Windows, and behind a repository-wide lock.
Purpose
iru-windows-code-one-task-group is the Windows desktop counterpart to iru-dotnet-code-one-task-group and
iru-kmp-code-one-task-group, built on the same iru-dotnet-* gate skills. It detects once the projects (app, UI-free
Core, Core tests, UI tests), the architecture, the host (Windows or not, with an interactive desktop session or not) and
the bucket’s validation scope: Core changes run Core gates, app-project changes add the compile check and the UI stage,
and packaging files are left to release.yml.
After one baseline capture via iru-dotnet-code-quality, it dispatches each task to iru-windows-code-one-task (all at
once when the bucket is Parallelizable: yes, otherwise one at a time; tasks that add and consume the same Core
interface, or edit the same XAML, designer file, DI registration or manifest, always run sequentially). Validation then
runs once, every check delegated to an iru-gate-runner agent: license headers, XML doc comments via
iru-dotnet-docfx, scoped Core tests via iru-dotnet-test, an 80% line-coverage gate on Core only via
iru-dotnet-coverage (the UI layer is reported "not measured", never 0%), the full non-UI suite, and a quality diff
against the baseline. Only then does the FlaUI UI stage run (iru-dotnet-test with the ui selector) behind the shared
atomic-mkdir .integration-test.lock (stale after 60 minutes, bounded wait of about 45 minutes, released on every exit
path) and passed to the gate as lock: held. Right after the UI stage comes the UI-contract check (Step 3.7c; see Building user interfaces):
from the bucket’s UI inventory (the Screen > Region > Component trees the tasks reported, plus .ui-quality.yml) it
verifies that every screen and component the bucket added or changed has a .ui-screenshots/<kind>/<Id>/ PNG for each
visual state x configured direction x theme, with no malformed names. Axe.Windows violations fail the bucket at
accessibility: enforce and are only listed at report. A UI stage, WinUI build or packaging step that cannot run (not Windows, no
interactive desktop, lock wait timeout) is reported "unverified", never skipped silently or reported as passed.
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.
Plugin
Shipped by the iru-dotnet plugin of the ai-catalog marketplace (install with /plugin install iru-dotnet@ai-catalog; see Plugins).
Inputs
| Argument | Required | Description | Default |
|---|---|---|---|
Bucket text |
Yes |
Every |
None — this skill is always invoked with a specific bucket’s text, by |
Outputs
-
Source, test and XAML/form changes per task, via
iru-windows-code-one-task. -
License headers and XML doc comments kept current across every file the bucket touched, checked once for the whole bucket.
-
Unit tests achieving at least 80% line coverage for the bucket’s changed or new Core classes, verified against the real coverlet report; app-project types reported as not measured, with any real logic in them flagged as belonging in Core.
-
A green non-UI suite and, on a capable Windows host, a green FlaUI UI stage — or an explicit "unverified" with the reason.
-
The UI-contract result: screenshots per kind and per screen/component, missing state x direction x theme combinations (fixed through the owning task, or why not), malformed names, and the accessibility level with its violations, or "unverified (needs Windows)" off Windows — never "passed" for lack of captures.
-
.integration-test.lock/taken and released around the UI stage only (and.gitignoreextended with it if missing). -
implementation_plan.mdwith each task’s checkbox checked and a "group validation pending" note first, replaced with the final outcome quoting Core coverage and the UI result separately; blocked tasks left unchecked with their note. -
User-facing notifications per task as its implementation lands and once when group validation completes, and a summary handed back to
iru-code-one-task-group: shape and scope, per-task details, Core and UI results, accepted coverage exceptions, lock behavior and any blocker.
Execution flow
Dependencies
Invokes
-
Windows Code One Task — Step 2, once per task in the bucket (concurrently or sequentially per the group’s
Parallelizableverdict, with sequential ordering forced for tasks that share a Core interface, a XAML file, a designer file, DI registration or a manifest), via theiru-isolated-skill-executoragent. Each run implements exactly what its task specifies, writes/updates its tests, compile-checks, and checks off its own checkbox with a "group validation pending" note.
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:
-
.NET Code Quality — Step 1 (pre-change baseline) and Step 3.6 (regression check against it).
-
Check License — Step 3.1, license headers for every C#, XAML and PowerShell file the bucket touched.
-
.NET DocFX — Step 3.2, XML doc comments and a passing DocFX build for every type touched.
-
.NET Test — Step 3.3 (scoped Core tests), Step 3.5 (full non-UI suite), and Step 3.7 (UI stage,
uiselector, withlock: held). -
.NET Coverage — Step 3.4, Core line/branch coverage with an 80% bar.
Invoked by
-
Code One Task Group — Step 2, bucket for key windows.
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), including the single UI-stage call (whose summary feeds the Step 3.7c UI-contract check), keeping full reports out of this skill’s context.
Source
SKILL.md on GitHub — the file this page was generated from.