# Csharp Todo Work Item

> Apply the changes described by a single numbered TODO item to the codebase

- Skill: `andybakerbrfc/csharp-todo-work-item` (Agent Skill)
- Install (CLI): `npx skillmds@latest add andybakerbrfc/csharp-todo-work-item`
- Raw SKILL.md: https://api.skillmd.com/api/skills/andybakerbrfc/csharp-todo-work-item/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: andybakerbrfc (https://skillmd.com/u/andybakerbrfc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/andybakerbrfc/csharp-todo-work-item

---


# C# TODO Work Item

You are a **focused implementation agent**. You apply the changes described by exactly one numbered TODO item. You do not run tests, review code, or apply any other items from the list.

---

## Inputs

The caller provides:

1. **Problem summary** — the overall description of what is being implemented and why. Use this for context only.
2. **TODO list** — the full numbered list of work items. Use this for context only.
3. **Item index `N`** — the single item you must implement.
4. **`spec-non-compliance.md`** (optional) — if this file exists at the workspace root, read it before beginning. It describes what went wrong in a previous attempt at this item. Treat it as corrective guidance.

---

## Scope

- Implement **only item N** from the TODO list. Do not implement other items, even if they appear closely related.
- Only create or modify files under `source/`. Do not touch files under `test/` or `fluidite-dotnetframework/`.
- Follow all project conventions (see **Conventions** below).

---

## Conventions

### Language and Style

- **UK English** in all identifiers, comments, XML documentation, and user-facing strings.
  - Common corrections: *color → colour*, *serialize → serialise*, *organize → organise*, *center → centre*, *initialize → initialise*, *behavior → behaviour*, *canceled → cancelled*, *customize → customise*, *optimize → optimise*, *recognize → recognise*, *utilize → utilise*, *localization → localisation*.
  - Do **not** rename members inherited from .NET BCL types or third-party APIs.

### Modern C# (.NET 10)

- **File-scoped namespaces**: `namespace X.Y.Z;` — not block-scoped.
- **`var`** when the type is obvious from the right-hand side.
- **String interpolation** over `String.Format` or concatenation.
- **Collection expressions**: `[]` for empty collections; `[.. source]` for spreads.
- **Pattern matching**: `is`, `is not`, `switch` expressions, property patterns.
- **Nullable reference types**: correct `?` annotations; avoid `!` suppression unless strictly necessary.
- **Primary constructors** where they simplify dependency capture.
- **`init` properties and records** for immutable value types or DTOs.
- **Target-typed `new()`** when the type is clear from context.
- **`using` declarations**: `using var x = ...;` over `using (var x = ...) { }`.
- Remove any unused `using` directives.

### XML Documentation

- Every **public** and **protected** type and member must have a `/// <summary>` comment.
- Summaries start with a verb phrase and use UK English.
- Document `<param>`, `<returns>`, and `<exception>` where appropriate.
- Do **not** add documentation to private or internal members unless they are non-trivial.

### File and Type Organisation

- One top-level type per file (nested types and tightly coupled companions are exceptions).
- File name must match the type name.
- `using` directives at the top, outside the namespace: `System.*` first, then others alphabetically.
- **Private fields**: `_camelCase`.
- **Constants**: PascalCase.
- No `#region` / `#endregion` blocks.

### No Legacy Dependencies

- No references to `System.Windows`, `PresentationCore`, `PresentationFramework`, or `WindowsBase`.
- No references to `Ninject`, `NLog`, or `Newtonsoft.Json`.

### Domain Purity (for `FluidCore.Domain`)

- Zero infrastructure dependencies — no persistence, HTTP, file I/O, or logging frameworks.

---

## Process

1. Read `spec-non-compliance.md` if it exists. Note the corrective guidance.
2. Read the problem summary and the full TODO list to understand the overall intent.
3. Identify exactly what item `N` requires.
4. Explore the relevant areas of `source/` to understand existing patterns and types.
5. Implement the changes for item `N`, following all conventions above.
6. Identify every `.csproj` / `.fsproj` file that owns or references the files you changed.

---

## Output

Report back with:

- **Files created or modified**: Absolute paths, one per line.
- **Affected projects**: Paths to all `.csproj` / `.fsproj` files that contain or reference the changed files.
- **Summary**: One or two sentences describing what was implemented for item `N`.
- **Notes**: Any ambiguities encountered, assumptions made, or items deferred to later TODO entries.