.NET Code One Task Group

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

Implement one bucket of .NET/C# tasks from a plan’s task group end to end: capture a single pre-change quality baseline, run iru-dotnet-code-one-task once per task (in parallel when the group allows it), then validate the entire bucket once — license headers, XML doc comments, scoped tests, coverage, a full-suite run, and a code-quality regression check.

Purpose

iru-dotnet-code-one-task-group is the .NET/C# counterpart to iru-java-code-one-task-group — same shape, built on iru-dotnet-code-quality, iru-dotnet-test, iru-dotnet-coverage, and iru-dotnet-docfx instead of the Maven/Java tool chain. It captures one pre-change quality baseline covering every type the bucket’s tasks are expected to touch, then implements each task via iru-dotnet-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-dotnet-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 (two parallel tasks finishing at nearly the same moment) clobbered it, and notifies the user that implementation landed — before group-wide validation runs. Once every task in the bucket has landed, it validates the whole bucket in one pass instead of once per task: license headers, XML doc comments, the affected test classes, 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.

Windows desktop app repositories (WPF, WinUI 3, Windows Forms; plan key windows) are out of scope: when a WinExe project sets UseWPF/UseWinUI/UseWindowsForms, this skill stops and hands the bucket to Windows Code One Task Group, which adds the Core-only coverage bar, host gating and the lock-serialized UI-test stage. The gate skills it calls are Windows-desktop aware on their own (UI-category tests are excluded by default and net*-windows* test projects are skipped off Windows), so a plain .NET repository with a small WinForms/WPF tool still validates here — its UI tests are just never run. The full-suite check calls iru-dotnet-test with no selector rather than a raw dotnet test.

Command-line tools. Before Step 1 the skill detects a CLI-shaped project (an Exe project on System.CommandLine with PublishAot/PackAsTool, as scaffolded by Setup Dotnet Cli: src/<Tool>, framework-free src/<Tool>.Core, tests/<Tool>.Core.Tests, tests/<Tool>.Cli.Tests). For that shape, coverage is measured only on changed Core classes (the thin command tree is reported "not measured" and covered behaviourally by the in-process CLI tests), the full suite includes tests/<Tool>.Cli.Tests, and two extra checks run when applicable. 3.7 is a Native AOT dotnet publish -r <host-rid> -c Release, run via the iru-gate-runner agent when the bucket touched the CLI project, Core or the build files; it must finish with zero IL trim/AOT warnings and the published-binary tests must pass, and a missing native toolchain makes it "unverified", never "passed". 3.8 regenerates the CLI reference when a command, argument or option changed and checks that the generated page is current. 3.9 is a terminal UI stage, run only when the bucket touched the optional Terminal.Gui UI (src/<Tool>/Tui/, a view, the hosting command, or Core state a view renders): the full suite excludes [TestCategory("UI")] tests, so it runs iru-dotnet-test with the ui selector (any host, no lock), checks that every changed screen and component has a .ui-screenshots/<kind>/<Id>/<state>--<direction>--no-color.txt capture for each visual state × .ui-quality.yml direction, and applies the asserted terminal accessibility checks (tui-color-only, tui-help-line, tui-keyboard) at the configured enforce/report/off/none level. A changed view with no UI tests is reported "terminal UI untested", never passed. See Building user interfaces.

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-dotnet-code-one-task-group <bucket text>

Inputs

Argument Required Description Default

Bucket text

Yes

Every .NET-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-dotnet-code-one-task.

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

  • For CLI-shaped projects: a Native AOT publish result (zero IL trim/AOT warnings, published-binary test counts, or "unverified" when no native toolchain is available) and a current generated CLI reference page; when the terminal UI was touched, the UI stage result (UI test counts, captures per view and any missing state × direction, malformed names, the accessibility level applied - or "accessibility: opted out" when .ui-quality.yml says none - and its violations).

  • Tests achieving at least 80% line coverage for the bucket’s changed/new classes, 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-dotnet-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.

  • A summary handed back to the caller (iru-code-one-task-group): per task, files touched, tests added/updated, coverage achieved, code-quality outcome, and any task that stopped on a blocker. 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.

Execution flow

flowchart TD A[Start /iru-dotnet-code-one-task-group] --> W{"Windows desktop app\nsolution?"} W -- yes --> W2["Stop: hand the bucket to\nwindows-code-one-task-group"] W -- no --> B["Step 1: capture one pre-change\nquality baseline for the whole bucket\n(iru-dotnet-code-quality, via iru-gate-runner)"] B --> C{Bucket Parallelizable?} C -- yes --> D["Step 2: invoke dotnet-code-one-task\nfor every task concurrently"] C -- no --> E["Step 2: invoke dotnet-code-one-task\nfor each task, one at a time"] D --> F["Confirm/backfill each task's box\n(set by dotnet-code-one-task itself); notify user"] E --> F F --> G["Step 3: validate the whole bucket once —\nlicense headers, XML doc comments,\nscoped tests, coverage, full suite,\nquality vs. baseline;\nCLI tools: Core-only coverage,\n3.7 Native AOT publish, 3.8 CLI reference,\n3.9 terminal UI stage if Tui touched"] G -- failure traced to a task --> H["Fix that task's implementation;\nre-run the affected check(s)"] H --> G G -- clean --> 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

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

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 for the bucket) and Step 3 (final regression check against that baseline).

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

  • .NET DocFX — Step 3, XML doc comments for every type the bucket touched.

  • .NET Test — Step 3, scoped tests for every type the bucket affected, plus a full-suite run; for a terminal-UI bucket, also the ui selector run (Step 3.9).

  • .NET Coverage — Step 3, coverage for every changed/new class in the bucket (CLI tools: Core classes only).

For CLI-shaped projects the Native AOT publish check (Step 3, item 7) is also delegated to iru-gate-runner, as a full project build (dotnet publish), not a catalog skill.

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.