| name | iru-dotnet-code-one-task |
| description | Implement a single task from a .NET `implementation_plan.md`-style task list — just the implementation and its tests. Re-checks the current code state, implements exactly what the task specifies, writes/updates test-framework tests (xUnit/NUnit/MSTest, whichever the project uses), then — if the task didn't stop on a blocker — immediately checks off this task's own checkbox (and its sub-tasks') in `implementation_plan.md` with a "group validation pending" note, so an interrupted run doesn't re-attempt work that already landed, before handing back a short summary (files touched, tests added/updated, and any blocker) for the caller to record. Does not capture a quality baseline, add license headers, update doc comments, run coverage/quality checks, or replace the pending note with the final validation outcome — those still happen once per task group in `iru-dotnet-code-one-task-group`, which is what invokes this skill once per task in a bucket (in parallel when the bucket allows it) and finalizes each checkbox's note once group validation passes. Invoke as `/iru-dotnet-code-one-task <task description>`, passing the task's own text — including its exact `implementation_plan.md` checkbox line(s), so this skill can find and flip them — as the argument. Equivalent to `iru-java-code-one-task` for .NET/C# projects. |
| model | sonnet |
| allowed-tools | Read Edit Write Bash(dotnet *) Bash(git status *) Bash(git diff *) Bash(git log *) Bash(find *) Bash(grep *) Bash(ls *) |
Implement one plan task (.NET)
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), then handles license headers, doc comments,
and all test/coverage/quality validation itself, once for the whole bucket, instead of repeating that validation
here for every single task. It uses a medium model on purpose — the plan already carries the hard reasoning;
this skill just executes one task's implementation.
Step 1 — Re-check the current code state
Read the actual current content of the file(s) the task touches before editing — don't assume any "current code
state" notes passed in with the task are still accurate; other tasks in the same bucket may be landing
concurrently, or the file may have changed for unrelated reasons.
Step 2 — Implement exactly what the task specifies
The named file(s), the described class/method/property, the behavior, the interface/base class it implements.
Follow this repository's conventions from CLAUDE.md (target framework/language version, var/nullable
reference type usage (only if code already uses it), full XML doc comments (<summary>/<param>/<returns>/
<exception>) on every public/protected member, ArgumentException/ArgumentNullException for invalid
arguments, no new NuGet dependencies). Don't add anything the task didn't ask for — no speculative abstractions,
no unrelated cleanup.
Step 3 — Write or update the tests
Follow the existing test style in the same project/namespace — whichever test framework this repository already
uses (xUnit, NUnit, or MSTest), and Moq/NSubstitute only where already used. Cover the new/changed behavior,
including edge cases implied by the XML doc <exception> contracts (e.g. null/invalid-argument cases). Do not
run the test suite yourself — iru-dotnet-code-one-task-group runs it once for the whole bucket in its own
consolidated validation pass.
Step 4 — When to interrupt the user
Keep interruptions rare — most tasks should complete unattended. Stop and use AskUserQuestion (or plain text if
no real choice is being offered) only when:
- Implementing the task reveals it's ambiguous in a way that changes correctness or scope and can't be safely
inferred — conflicting instructions, a choice only the user can make (e.g. which of two APIs to break), or a
missing decision. Don't ask about things with an obvious best-practice answer.
- The task's described approach appears infeasible against the real code as it stands (e.g. it names a type or
member that doesn't exist and isn't a trivial typo) — not something you can resolve by writing the code
slightly differently.
Do not stop merely because the task is nontrivial — implement it. Do not report the task done to work around a
blocker; report it as blocked instead (Step 6), with enough detail — what was tried, what failed, why — for the
caller to surface it.
Step 5 — Check off this task's checkbox now
If this task did not stop on a blocker (Step 4), update implementation_plan.md at the repository root before
reporting back — don't leave this for the caller. Re-read the file fresh (not any earlier cached view — other
tasks in the same bucket may be landing concurrently) and locate this task's own checkbox line by the exact text
passed in with the task. Flip its [ ] to [x], and do the same for every sub-task checkbox that was part of
the work just completed, adding a short note naming the files touched, e.g. - [x] Task 2. **Implement SimpleWidget** — implemented, tests added; group validation pending. — the same "pending" wording
iru-dotnet-code-one-task-group uses, since the coverage/quality outcome isn't known until it validates the
whole bucket in its own Step 3/4. Edit only this task's own line(s) — never rewrite surrounding lines or other
tasks' checkboxes, since sibling tasks in a parallel bucket may be editing this same file at nearly the same
moment. This is what lets an interrupted run resume without re-attempting a task whose implementation and tests
already landed, even if the interruption happened before iru-dotnet-code-one-task-group got to run its own
group-wide validation.
If this task stopped on a blocker instead, leave its checkbox untouched — there's nothing finished to mark done.
Step 6 — Report the outcome
Hand control back to the caller with a short summary: the file(s) touched, the tests added/updated, and whether
this task stopped on a blocker per Step 4. This is what iru-dotnet-code-one-task-group records for this task before
running its own consolidated license/doc/test/coverage/quality validation across the whole bucket; this skill
has already checked off this task's own checkbox with a pending-validation note (Step 5) — the caller only needs
to replace that note with the final validation outcome once the whole bucket passes, not create the checkbox
entry itself. This skill itself never captures a quality baseline and never runs tests/coverage/quality checks.
