dotnet-writing-plans

# .NET Writing Plans

## Overview

Every implementation plan is a self-contained instruction set: an engineer with zero codebase context should be able to execute it task-by-task using only the plan and TDD.

Write bite-sized tasks with exact file paths, complete code, and explicit test specs. DRY. YAGNI. TDD. Frequent commits. Assume the implementer is skilled but knows nothing about our toolset, problem domain, or good test design — be explicit about what to test and what NOT to test.

**Announce at start:** "I'm using the dotnet-writing-plans skill to create the implementation plan."

**REQUIRED CONTEXT:** Run in a dedicated worktree (created by `superpowers:brainstorming`).

**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`

## When NOT to Use
- Single-file bug fix with obvious cause and fix
- Config/environment changes (appsettings, launchSettings, .csproj tweaks)
- Renaming or moving files without logic changes
- Adding a NuGet package with no code changes beyond the import

## Test Quality Rules for Plan Writers

**These rules apply to EVERY test you spec in a plan. Violations mean the plan is broken.**

### NEVER spec these tests:
- Getter/setter tests (`CanSetName`, `CanSetProperties`, `HasInitializedCollections`)
- Tests that verify a property is nullable/not-null by default
- Tests that assert a constructor assigns values to properties
- Tests that check framework behavior (EF navigation properties, DI resolution)

### Every test MUST:
- **Verify behavior that could have a bug.** Ask: "What bug does this catch?" If the answer is "none" — delete the test from the plan.
- **Have max 3 assertions.** More than 3? Split into separate tests.
- **Use `[Theory]`+`[InlineData]` for multiple inputs** of the same behavior (e.g., empty string, null, whitespace all invalid).
- **Follow naming: `MethodName_Scenario_ExpectedBehavior`** — not `Test1`, `ItWorks`, `CanSetName`.

### Phase 1 of every plan MUST include:
- Shared test infrastructure setup (`CustomW