Windows Code One Task

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

Implement a single task from a Windows desktop app implementation_plan.md-style task list — just the implementation, its tests and the checkbox update — detecting the UI stack, architecture and host at runtime and loading only the matching guidance from the skill’s own reference/ directory.

Purpose

iru-windows-code-one-task is the narrowest execution unit for a windows task in the iru-code pipeline, and the Windows desktop counterpart of iru-dotnet-code-one-task. It detects the UI stack from the app *.csproj (UseWPF, UseWinUI, UseWindowsForms), the architecture from the UI-free Core project (ViewModels/ for MVVM with CommunityToolkit.Mvvm, Controllers/ plus Views/I<X>View.cs for MVC), the test framework and runner, packaging files and the host OS, then reads reference/README.md and only the files the task needs (code style and architecture always; the UI contract pair for UI work; testing, XML docs, MVVM Toolkit or MVC, one of WPF/WinUI/WinForms, packaging, security as relevant).

Two things set it apart from the plain .NET skill. Logic lives in src/<App>.Core (plain net10.0), where the 80% coverage bar is measured, so deciding where code goes comes first and UI types never enter Core. And part of the solution only builds or runs on Windows: WPF and WinForms compile elsewhere with EnableWindowsTargeting, but a WinUI project cannot, and "unavailable" is never reported as "passed". It writes or updates tests in the right project, compile-checks each touched project, then checks off its own checkbox with a "group validation pending" note. It does not capture a quality baseline, add license headers, run tests, coverage or analyzers, launch the app or package anything; the group skill does those once per bucket.

For tasks that add or change UI it follows the catalog’s UI contract (reference/ui-contract.md and reference/ui-implementation.md; see Building user interfaces): it first writes the Screen > Region > Component decomposition with each component’s inputs, events and visual states and searches for existing UserControl`s or templates to reuse, then builds leaves, composed components, screens and navigation — UI-state records in Core, `UserControl`s with dependency-property inputs and command or `EventHandler<T> outputs, and collections in a virtualizing recycling container over a keyed ObservableCollection. Its tests include FlaUI screen/component/flow tests that capture .ui-screenshots/ PNGs per state across left-to-right/right-to-left x light/dark and run an Axe.Windows accessibility check at the .ui-quality.yml level (UiQuality, UiScreenshots and AccessibilityCheck helpers, added if missing; the Axe.Windows package only when the plan names it, otherwise reported).

Purpose group

.NET Development Tooling

Plugin

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

Invocation

/iru-windows-code-one-task <task description>

Inputs

Argument Required Description Default

Task description

Yes

The task’s own text, including its exact implementation_plan.md checkbox line(s) and its sub-tasks' text, plus any relevant "Current code state" context.

None — always invoked with a specific task’s text, normally by iru-windows-code-one-task-group.

Outputs

  • Production code in the right project: Core models, services, view models or controllers first, then app-project service implementations, XAML or forms and DI registration, with XML doc comments on every public/protected member.

  • New or updated tests: tests/<App>.Core.Tests for Core logic and, only when the task asks, a [TestCategory("UI")] FlaUI test in tests/<App>.UITests — written but not run. A task that adds or changes a screen or component always adds its UI tests: every visual state, a screenshot capture per state x direction x theme, and an accessibility check.

  • For a UI task, the component tree in the report and the screenshot names the new tests will produce (<kind>/<Id>/<state>--<dir>--<theme>.png).

  • A per-project compile-check (dotnet build, with -p:EnableWindowsTargeting=true off Windows; a WinUI app project is reported "compile-check unavailable (needs Windows)").

  • implementation_plan.md with this task’s checkbox (and its sub-tasks') checked and a "group validation pending" note; left untouched if the task stopped on a blocker.

  • A short summary: shape detected (ui, architecture, Core project, test runner, host), projects and files touched, tests added (for a UI task: the decomposition and the UI tests with their capture names), compile-check result per project, bindings or DI registrations only a run can verify, blockers and any deviation from reference/.

Execution flow

flowchart TD A[Start /iru-windows-code-one-task] --> B["Step 0: detect solution, UI stack,\nCore project, architecture, tests,\npackaging, host OS"] B --> C{"App project found?"} C -- no --> C1[Report blocker: task mis-tagged] C -- yes --> D["Step 1: decide project(s);\nread reference/README.md and only\nthe files the task needs"] D --> E["Step 2: re-read current code,\nbound views and DI registration"] E --> F["Step 3: implement exactly the task\n(Core first, then app project, XAML, DI)"] F --> G["Step 4: write/update tests\nin the right test project (not run)"] G --> H["Step 5: dotnet build each touched project\n(EnableWindowsTargeting off Windows;\nWinUI unavailable off Windows)"] H --> I{"Build failure?"} I -- in this task's code --> F I -- outside scope --> J["Re-run once; note in report"] I -- no --> K J --> K{"Step 6: blocker or\nneeds user decision?"} K -- yes --> L["Ask user / report blocked;\nleave checkbox untouched"] K -- no --> M["Step 7: check off this task's\ncheckbox with 'group validation\npending' note"] M --> N["Step 8: report outcome"] L --> N

Dependencies

Invokes

None. iru-windows-code-one-task does not invoke any other catalog skill or spawn any agent — it only reads its reference/ files, edits the code, test and plan files the task names, and runs dotnet build directly for compile-checks.

Invoked by

  • Windows Code One Task Group — Step 2, once per task in a bucket (concurrently, in a single batch of Agent calls, when the group is marked parallelizable; one at a time otherwise), via the iru-isolated-skill-executor agent, passing that task’s full text including its exact checkbox line(s). That caller confirms the checkbox landed, then replaces the "pending" note with the final validation outcome.

The scaffold layout it assumes is the one written by Setup Windows App.

Related agents

None spawned by this skill itself; it is run inside an iru-isolated-skill-executor agent by its caller.

Source

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