.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), checking off each task’s box in
implementation_plan.md and notifying the user as its implementation lands — 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.
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 |
None — this skill is always invoked with a specific bucket’s text, by |
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.
-
Tests achieving at least 80% line coverage for the bucket’s changed/new classes, verified against the real coverage report.
-
implementation_plan.mdwith each task’s (and sub-task’s) checkbox checked and a progress note — first an "implemented, group validation pending" note 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, files touched, tests added/updated, coverage achieved, code-quality outcome, and any task that stopped on a blocker.
Execution flow
Dependencies
Invokes
-
.NET Code One Task — Step 2, once per task in the bucket (concurrently or sequentially per the group’s
Parallelizableverdict), via theiru-isolated-skill-executoragent — that skill implements exactly what the task specifies and writes/updates its tests, nothing more.
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.
-
.NET Coverage — Step 3, coverage for every changed/new class in the bucket.
Invoked by
-
Code One Task Group — Step 2, once for the whole bucket of tasks tagged
dotnet, via a directSkillcall.
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.