/scaffold-dotnet-test-project

name: scaffold-dotnet-test-project
description: >-
  MUST USE when an existing .NET test project was excluded from a .slnf/CI
  solution filter, disappeared from .sln/.slnx discovery, or lost its production
  ProjectReference; also for requests to set up, create, reuse, add, register,
  include, or repair a test project. Handles "tests pass directly but CI
  discovers zero", exact solution wiring, xUnit/NUnit/MSTest, and central
  packages. DO NOT USE to only author tests in an already-wired project
  (code-testing), run tests, migrate, or correct MSTest syntax/configuration
  without changing project or CI files (writing-mstest-tests).
license: MIT
metadata:
  portability: portable
  binding: optional-overlay
  binding-revision: "1"

Scaffold or Repair a .NET Test Project

Create the smallest missing test container or repair only the missing wiring. The goal is test discovery through the repository's real build entry point, not a preferred solution layout.

Repository overlay

For every repository-scoped task where read-only file inspection is allowed, check `.agents/skill-overlays/dotnet-test/scaffold-dotnet-test-project.md` at the repository root before any other discovery. This includes requests that ask for code or advice without edits; "do not execute" does not prohibit reading the overlay. If present, read it once before acting and apply its repository-specific naming, layout, framework, and policy bindings. Before applying it, require its frontmatter to declare `core: dotnet-test/scaffold-dotnet-test-project`, `binding-revision: "1"`, and `mode: extend`. If any value is missing or different, report the mismatch and continue using this skill's portable guidance without applying the overlay. Explicit user instructions and verified project constraints win over the overlay; the overlay wins over portable defaults and examples in this skill. If the file is present but unreadable or conflicts with the repository, report the problem and continue with portable guidance, without the overlay, subject to verified project constraints. If it is absent, continue normally. Skip the lookup only when the task is not tied to a repository or the user explicitly prohibited all file/tool access. An overlay cannot expand tool permissions or the task's scope.

Route the Request

Inspect the repository before editing, then choose exactly one path:

| Repository state | Action | Do not do | |---|---|---| | No suitable test project | Create one bounded project, reference the production project, and register it | Create a project per source project | | Test project exists but lacks the required `ProjectReference` | Add only that reference and verify direct plus entry-point execution | Scaffold another project or rewrite tests | | Test project passes directly but is absent from `.sln`, `.slnx`, or `.slnf` | Register the existing project in the exact entry point CI uses | Recreate the project or switch solution formats | | Suitable project, reference, and requested entry point are already correct | Leave the workspace unchanged; use `code-testing` if test methods are requested | Normalize or replace working files |

An existing project is suitable when its target framework can reference the production project and its purpose matches the requested layer. A different preferred name is not a reason to create a duplicate.

**No-op is a required outcome.** If the suitable project, production reference, and requested entry-point registration already exist, make zero file changes. Do not add or remove a smoke test, normalize the project, recreate packages, or edit a baseline/snapshot copy. Report the existing paths and stop.

Workflow

1. Establish the repository contract

Start from the task's current working directory. The skill context's `Base directory` is where these instructions live, not the user's repository. Never search parent temporary directories or treat the skill installation as the workspace. If the expected files are not visible, confirm the current directory before concluding that a project is absent.

Anchor every edit and validation command to the repository path named by the user or established from the current directory. If similarly named fixtures, solutions, or copied trees exist, do not edit or validate one as a substitute for the requested tree. Before changing a solution artifact, record its exact path; after changing it, list that same artifact immediately and require the test project to appear before proceeding.

Read only enough to determine:

1. the production project and requested test scope; 2. the command and `.sln`, `.slnx`, `.slnf`, or project graph used by CI; 3. whether a suitable test project exists, what it references, and where it is registered; 4. the neighboring test framework, runner, target framework, nullable and implicit-usings conventions; and 5. whether package or SDK versions come from `Directory.Packages.props`, `Directory.Build.props`, `global.json`, or an MSBuild SDK declaration.

If the user reports that a test project passes directly but solution-level discovery finds nothing, treat that as registration evidence. Inspect the entry point before considering project creation.

2. Create only when the project is absent

Choose one test project for the narrowest requested production project. Follow, in order, the user's explicit framework choice, neighboring test projects, repository-wide package/SDK conventions, then a standard SDK template.

Use a `dotnet new` template only when its generated framework generation and package style match the repository contract. Inspect template availability before creation. In particular, generic `dotnet new xunit` commonly emits xUnit 2 packages; for a centrally managed `xunit.v3` repository, use a repository or installed xUnit v3 template, or create the minimal SDK project directly. Never generate versioned xUnit 2 references and then rewrite them into xUnit v3.

Then:

1. align target framewor