.NET Code One Task

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

Carry out a single task’s implementation, tests, and checkbox update against the real codebase — nothing else. This is the narrowest execution unit in the iru-code pipeline: iru-dotnet-code-one-task-group calls it once per task in a bucket (potentially many at once, in parallel agents). It is the .NET/C# counterpart to iru-java-code-one-task.

Purpose

iru-dotnet-code-one-task is the .NET-specific implementation worker iru-dotnet-code-one-task-group calls once per task. Given one task’s own text (what to build, the named file(s)/type(s)/method(s), the described behavior, its exact implementation_plan.md checkbox line(s), and any sub-tasks), it re-checks the current code state, implements exactly what’s specified, and writes/updates tests in whichever framework this project already uses. If the task didn’t stop on a blocker, it then immediately checks off that task’s own checkbox (and its sub-tasks') in implementation_plan.md with a "group validation pending" note, before reporting back — so an interrupted run doesn’t re-attempt work that already landed, even if the interruption happens before the group’s own validation runs. License headers, XML doc comments, scoped tests, coverage, the full suite, code-quality regression checks, and replacing the pending note with the final validation outcome no longer happen here; they moved to iru-dotnet-code-one-task-group, which validates them once for the whole bucket of tasks instead of once per task, cutting the redundant tool invocations that used to happen here for every single task. It hands back only a short summary; it never captures a quality baseline or runs any test/coverage/quality check itself.

CLI-shaped projects. Step 0 detects a command-line tool: a .csproj with OutputType Exe, none of UseWPF/UseWinUI/UseWindowsForms, and a System.CommandLine (or Spectre.Console.Cli) reference or PackAsTool/PublishAot (iru-explore reports Project type: cli-tool (dotnet)). When it applies, the skill reads reference/README.md, reference/cli.md (System.CommandLine 2.0 patterns, Spectre.Console under the colour policy, Native AOT/trimming rules, testing commands in-process) and, for tasks that add or change a command, flag, output, error or exit path, reference/cli-contract.md (streams, exit codes, TTY/colour/prompts, JSON envelope, safety). Logic goes in the framework-free src/<Tool>.Core, commands stay thin in src/<Tool>/Commands/, new JSON output types are registered in the source-generated JSON context, and exit codes/error envelope are never renumbered or reshaped. After implementing, it runs dotnet build -c Release on each touched project so trim/AOT analyzer (IL2xxx/IL3xxx), StyleCop and CA errors surface immediately, and regenerates the CLI reference (or flags it as still needed). Tests go in tests/<Tool>.Core.Tests and, through the in-process runner, tests/<Tool>.Cli.Tests. When the task adds or changes the optional Terminal.Gui terminal UI (a Terminal.Gui reference, src/<Tool>/Tui/, a browse-style command) it also reads reference/ui-contract.md (the catalog’s UI contract) and reference/ui-implementation.md (composed View screens and components over Core state, ListView/TableView data sources, view tests on the ANSI driver). It decomposes the UI into a Screen › Region › Component tree first, keeps state and transitions in Core, and writes [TestCategory("UI")] view tests in tests/<Tool>.Cli.Tests/Tui/ that render every visual state × .ui-quality.yml direction at a fixed size, assert keyboard behaviour once, capture .ui-screenshots/<kind>/<Id>/<state>--<direction>--no-color.txt through UiScreenshots.SaveText, and apply the asserted tui- accessibility checks via AccessibilityCheck.Apply (helpers added when missing). See Building user interfaces. For any other project the reference/ directory is not read.

Windows desktop app repositories (a WinExe project with UseWPF, UseWinUI or UseWindowsForms; iru-explore’s `windows-app, plan key windows) are out of scope: the skill stops and hands the request to Windows Code One Task (which knows the UI-free Core project split, MVVM/MVC layouts and host-dependent compile checks), even for tasks that only touch that repository’s src/<App>.Core project.

A command-line tool project (an Exe project on System.CommandLine, as scaffolded by Setup Dotnet Cli) is detected in a new Step 0; only then does the skill load its reference/ files and compile-check the projects it touched.

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 <task description>

Inputs

Argument Required Description Default

task description

Yes

The task’s full text as written in implementation_plan.md — what to build, the named file(s)/type(s)/ method(s), the described behavior, its exact implementation_plan.md checkbox line(s) for itself and its sub-tasks, and any sub-tasks, plus any relevant "Current code state" context. Normally supplied by iru-dotnet-code-one-task-group dispatching one task in a bucket at a time.

None — this skill has nothing to do without a task description.

Outputs

  • Source and test files created/modified per the task, following this repository’s conventions from CLAUDE.md (target framework/language version, var/nullable reference types only where already used, full XML doc comments, ArgumentException/ArgumentNullException for invalid arguments, no new NuGet dependencies).

  • For CLI-shaped projects: Core logic/result records/error codes in src/<Tool>.Core, thin commands registered in the root command, JSON output types registered in the source-generated context, and a regenerated (or flagged) CLI reference page.

  • For terminal-UI tasks: composed View`s in `src/<Tool>/Tui/, [TestCategory("UI")] view tests in tests/<Tool>.Cli.Tests/Tui/, and the UiScreenshots/AccessibilityCheck helpers when absent; captures land in .ui-screenshots/ as text files when the group runs the ui selector.

  • Tests added/updated in this project’s existing test framework, covering the new/changed behavior — not run by this skill; the caller runs them once for the whole bucket.

  • implementation_plan.md with this task’s own checkbox (and its sub-tasks') checked off and a "group validation pending" note, written immediately once the task finishes cleanly — before this skill reports back, and before the caller’s own group-wide validation runs. Left untouched if the task stopped on a blocker.

  • A short summary handed back to the caller: file(s) touched, tests added/updated, for a terminal-UI task the Screen › Region › Component decomposition and the UI tests with the captures they produce, and whether the run stopped on a blocker.

Execution flow

flowchart TD A["Start /dotnet-code-one-task\n(task description)"] --> W{"Windows desktop app\n(WinExe + UseWPF/UseWinUI/\nUseWindowsForms)?"} W -- yes --> W2["Stop: hand the request to\nwindows-code-one-task"] W -- no --> X{"Step 0: CLI-shaped\n(Exe + System.CommandLine)?"} X -- yes --> X2["Read reference/README.md, cli.md,\ncli-contract.md (+ ui-contract.md,\nui-implementation.md for terminal UI)"] X -- no --> B X2 --> B["Step 1: re-check current\ncode state from disk"] B --> C["Step 2: implement exactly what the task specifies\n(CLI: also dotnet build -c Release\nfor trim/AOT errors; TUI: decompose first)"] C --> D["Step 3: write/update tests\n(xUnit/NUnit/MSTest; TUI: UI view tests;\nnot run here)"] D --> E{"Ambiguous, or approach\ninfeasible against real code?"} E -- yes --> F["Step 4: stop; leave checkbox\nunchecked; report blocker to caller"] E -- no --> G["Step 5: check off this task's\ncheckbox + 'validation pending' note"] G --> H["Step 6: report outcome\nto caller: files, tests"]

Dependencies

Invokes

None — iru-dotnet-code-one-task is a leaf skill; it does not call any other skill in this catalog (it only reads its own reference/ files for CLI-shaped projects). License headers, XML doc comments, scoped tests, coverage, and quality checks all moved to iru-dotnet-code-one-task-group.

Invoked by

  • .NET 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: yes; 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 re-reads implementation_plan.md afterward to confirm the checkbox this skill already flipped landed, backfilling it only if a rare concurrent-write race clobbered it, then replaces the "pending" note with the final validation outcome once the whole bucket’s validation passes.

Related agents

iru-dotnet-code-one-task itself does not spawn any Agent — it only reads and edits the code/test files the task names.

Source

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