[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699FNEXSYWFZDF4PKHE4BCB":3,"skill-same:01M699FNEXSYWFZDF4PKHE4BCB":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M699FNEXSYWFZDF4PKHE4BCB","scaffold-dotnet-test-project",null,"MUST USE when an existing .NET test project was excluded from a .slnf\u002FCI solution filter, disappeared from .sln\u002F.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\u002FNUnit\u002FMSTest, and central packages. DO NOT USE to only author tests in an already-wired project (code-testing), run tests, migrate, or correct MSTest syntax\u002Fconfiguration without changing project or CI files (writing-mstest-tests).","microsoft\u002Ftestfx","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699C71CJ91B5WZ3AXG3GG2M",1058,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscaffold-dotnet-test-project\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"test","dotnet","scaffold dotnet test project","scaffold","project","ci","when","overlay","wiring","filter","files","up","only","migrate","SET","testing","code","create","packages","mstest","writing","2026-11-10 10:12:30",false,"---\nname: scaffold-dotnet-test-project\ndescription: >-\n  MUST USE when an existing .NET test project was excluded from a .slnf\u002FCI\n  solution filter, disappeared from .sln\u002F.slnx discovery, or lost its production\n  ProjectReference; also for requests to set up, create, reuse, add, register,\n  include, or repair a test project. Handles \"tests pass directly but CI\n  discovers zero\", exact solution wiring, xUnit\u002FNUnit\u002FMSTest, and central\n  packages. DO NOT USE to only author tests in an already-wired project\n  (code-testing), run tests, migrate, or correct MSTest syntax\u002Fconfiguration\n  without changing project or CI files (writing-mstest-tests).\nlicense: MIT\nmetadata:\n  portability: portable\n  binding: optional-overlay\n  binding-revision: \"1\"\n---\n\n# Scaffold or Repair a .NET Test Project\n\nCreate the smallest missing test container or repair only the missing wiring.\nThe goal is test discovery through the repository's real build entry point, not\na preferred solution layout.\n\n## Repository overlay\n\nFor every repository-scoped task where read-only file inspection is allowed,\ncheck `.agents\u002Fskill-overlays\u002Fdotnet-test\u002Fscaffold-dotnet-test-project.md` at\nthe repository root before any other discovery. This includes requests that\nask for code or advice without edits; \"do not execute\" does not prohibit\nreading the overlay. If present, read it once before acting and apply its\nrepository-specific naming, layout, framework, and policy bindings.\nBefore applying it, require its frontmatter to declare\n`core: dotnet-test\u002Fscaffold-dotnet-test-project`, `binding-revision: \"1\"`, and\n`mode: extend`. If any value is missing or different, report the mismatch and\ncontinue using this skill's portable guidance without applying the overlay.\nExplicit user instructions and verified project constraints win over the\noverlay; the overlay wins over portable defaults and examples in this skill. If\nthe file is present but unreadable or conflicts with the repository, report the\nproblem\nand continue with portable guidance, without the overlay, subject to verified\nproject constraints. If it is absent, continue normally. Skip the lookup only\nwhen the task is not tied to a repository or the user explicitly prohibited all\nfile\u002Ftool access. An overlay cannot expand tool permissions or the task's scope.\n\n## Route the Request\n\nInspect the repository before editing, then choose exactly one path:\n\n| Repository state | Action | Do not do |\n|---|---|---|\n| No suitable test project | Create one bounded project, reference the production project, and register it | Create a project per source project |\n| 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 |\n| 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 |\n| 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 |\n\nAn existing project is suitable when its target framework can reference the\nproduction project and its purpose matches the requested layer. A different\npreferred name is not a reason to create a duplicate.\n\n**No-op is a required outcome.** If the suitable project, production reference,\nand requested entry-point registration already exist, make zero file changes.\nDo not add or remove a smoke test, normalize the project, recreate packages, or\nedit a baseline\u002Fsnapshot copy. Report the existing paths and stop.\n\n## Workflow\n\n### 1. Establish the repository contract\n\nStart from the task's current working directory. The skill context's `Base\ndirectory` is where these instructions live, not the user's repository. Never\nsearch parent temporary directories or treat the skill installation as the\nworkspace. If the expected files are not visible, confirm the current directory\nbefore concluding that a project is absent.\n\nAnchor every edit and validation command to the repository path named by the\nuser or established from the current directory. If similarly named fixtures,\nsolutions, or copied trees exist, do not edit or validate one as a substitute\nfor the requested tree. Before changing a solution artifact, record its exact\npath; after changing it, list that same artifact immediately and require the\ntest project to appear before proceeding.\n\nRead only enough to determine:\n\n1. the production project and requested test scope;\n2. the command and `.sln`, `.slnx`, `.slnf`, or project graph used by CI;\n3. whether a suitable test project exists, what it references, and where it is\n   registered;\n4. the neighboring test framework, runner, target framework, nullable and\n   implicit-usings conventions; and\n5. whether package or SDK versions come from `Directory.Packages.props`,\n   `Directory.Build.props`, `global.json`, or an MSBuild SDK declaration.\n\nIf the user reports that a test project passes directly but solution-level\ndiscovery finds nothing, treat that as registration evidence. Inspect the entry\npoint before considering project creation.\n\n### 2. Create only when the project is absent\n\nChoose one test project for the narrowest requested production project. Follow,\nin order, the user's explicit framework choice, neighboring test projects,\nrepository-wide package\u002FSDK conventions, then a standard SDK template.\n\nUse a `dotnet new` template only when its generated framework generation and\npackage style match the repository contract. Inspect template availability\nbefore creation. In particular, generic `dotnet new xunit` commonly emits xUnit\n2 packages; for a centrally managed `xunit.v3` repository, use a repository or\ninstalled xUnit v3 template, or create the minimal SDK project directly. Never\ngenerate versioned xUnit 2 references and then rewrite them into xUnit v3.\n\nThen:\n\n1. align target framework, nullable, implicit usings, runner, and package style;\n2. use `dotnet add \u003Ctest-project> reference \u003Cproduction-project>` for only the\n   production projects exercised by the requested tests;\n3. delete template sample files such as `UnitTest1.cs`, then create a\n   behavior-named test file rather than repurposing the template filename; and\n4. omit package versions when central package management supplies them.\n\nFor xUnit v3 projects using the MTP runner, preserve or add executable output\nin both command modes, and retain the repository's framework runner opt-in:\n\n```xml\n\u003COutputType>Exe\u003C\u002FOutputType>\n```\n\nOnly when `dotnet test` uses VSTest command mode to bridge to MTP (SDK 8\u002F9,\nor SDK 10+ without native MTP mode), preserve or add:\n\n```xml\n\u003CTestingPlatformDotnetTestSupport>true\u003C\u002FTestingPlatformDotnetTestSupport>\n```\n\nFor SDK 10+ native MTP mode selected by `global.json` `test.runner`, do not add\nthe compatibility property; remove an explicit bridge setting when configuring\nnative mode. Keep executable output and the MTP runner enabled.\n\n`OutputType=Exe` alone proves only the self-hosted runner path, not discovery by\nthe repository's `dotnet test` command. Verify the exact command mode and\nentry-point execution as described in `run-tests`: native MTP uses `--project`\nor `--solution` with direct MTP arguments; VSTest-mode MTP uses a positional\npath and passes MTP arguments after `--`.\n\n### 3. Repair only the missing edge when the project exists\n\n- Missing production reference: use `dotnet add \u003Ctest-project> reference\n  \u003Cproduction-project>`, inspect the resulting project, and leave every other\n  project element plus all test source files unchanged. Compare the project\n  before and after so the added `ProjectReference` is the only semantic change.\n- Missing `.sln` or `.slnx` registration: run `dotnet sln \u003Centry-point> add\n  \u003Ctest-project>`, then immediately run `dotnet sln \u003Centry-point> list` against\n  that exact path. If the project is absent, the repair has not happened; do not\n  validate a sibling solution or report success.\n- Missing `.slnf` registration: add the existing project to its underlying\n  solution if necessary, then include that same project path in the filter. If\n  the underlying solution already contains it, edit only the filter.\n- Multiple solution artifacts: modify only the one named by the user or invoked\n  by CI. Do not substitute an easier format.\n- No solution artifact: preserve the existing project-oriented workflow. Do not\n  create a solution for aesthetics.\n\n### 4. Add only the requested smoke behavior\n\nFor a newly created project, replace template examples with the smallest smoke\nsuite the user requested. Each test must invoke a real production symbol and\nassert a concrete deterministic result without network, wall-clock, process, or\nreal-filesystem dependencies.\n\nFor an existing-project wiring repair, do not add, rewrite, rename, or expand\ntests unless the user explicitly asks for test behavior changes. Registration\nand test authoring are separate operations.\n\n### 5. Verify the repaired path\n\nSelect direct-project and entry-point commands using\n[`run-tests`](..\u002Frun-tests\u002FSKILL.md) and\n[`platform-detection`](..\u002Fplatform-detection\u002FSKILL.md). Resolve the project\nsystem, `global.json` `test.runner`, and final imported runner, `UseVSTest`,\n`TestingPlatformDotnetTestSupport`, and `OutputType` values; do not select\nsyntax from the SDK version alone.\n\n| Detected mode \u002F platform | Direct-project command | Solution entry-point command |\n|---|---|---|\n| Classic non-SDK | Repository's documented build and test-runner command for the test project | Exact repository\u002FCI build and test-runner command; do not substitute `dotnet test` |\n| VSTest mode \u002F VSTest | `dotnet test \u003Ctest-project>` | `dotnet test \u003Centry-point>` |\n| VSTest mode \u002F executable MTP bridge, including SDK 10+ | `dotnet test \u003Ctest-project> -- \u003CMTP_OPTIONS>` | `dotnet test \u003Centry-point> -- \u003CMTP_OPTIONS>` |\n| SDK 10+ native MTP mode selected by `test.runner=Microsoft.Testing.Platform` | `dotnet test --project \u003Ctest-project> \u003CMTP_OPTIONS>` | `dotnet test --solution \u003Centry-point> \u003CMTP_OPTIONS>` |\n\nMTP options are optional; when none are needed, omit both `\u003CMTP_OPTIONS>` and\nthe bridge separator. Keep dotnet\u002FMSBuild options before `--` in bridge mode;\nnative MTP options are direct arguments, never after `--`. These are command\nshapes, not replacements for a repository script or a project-oriented CI\nentry point. Preserve the exact configured entry point and report incompatible\nrunner\u002Fbridge\u002Foutput wiring rather than switching runners to obtain a green\nresult.\n\nRun the narrowest commands that prove the chosen route:\n\n| Route | Required evidence |\n|---|---|\n| Newly created project | Mode-appropriate direct-project test command, the exact entry-point command CI uses, and registration listing. If the entry point is a `.slnf`\u002F`.slnx` containing tests, run the mode-appropriate test command on that artifact rather than proving only that it builds. |\n| Missing reference | Targeted project test plus the exact solution\u002Froot test command requested |\n| Missing `.sln`\u002F`.slnx` registration | Listing and the mode-appropriate test command for that exact artifact; never use another solution as a fallback |\n| Missing `.slnf` entry | Inspect the filter entry and run the exact CI filter build command; do not prepend a deliberately failing alternate command |\n| Already correct\u002Fno-op | Structural inspection of the existing reference and registration. Unless execution was requested, do not run tests merely to prove a no-op because that creates `bin`\u002F`obj` and weakens byte-for-byte cleanliness evidence. |\n\nInspect the repository's command before adding switches. Do not prepend a\nspeculative `--no-restore` attempt or hide alternatives in `command-a ||\ncommand-b`; run the configured entry-point command whose clean exit is the\nevidence.\n\nFor every wiring repair, invoke the exact validation command directly and\npreserve its exit status. Reading generated files, a grader script, or a later\nbuild is not a substitute for observing that command complete successfully.\n\nBefore reporting completion, inspect the final changed-file set. Remove only\n`bin`\u002F`obj` or equivalent build artifacts created by this task when they were\nabsent beforehand and are not intentionally tracked; never remove pre-existing\nartifacts. Preserve the passing command's complete result so the handoff can\nstate the exact entry point and discovered test count.\n\nFor a no-op, inspect rather than rewrite and report the existing paths. A green\n`dotnet build` is not test-discovery evidence. If validation is blocked, report\nthe exact failing command and first actionable error; never describe an unrun or\nfailed command as successful.\n\n## Output\n\nKeep the handoff proportional to the change:\n\n| Requirement | Evidence |\n|---|---|\n| Project created, reused, or repaired | Test project path and chosen route |\n| Production reference | Referenced `.csproj`, or why no change was needed |\n| Build registration | Exact `.sln`\u002F`.slnx`\u002F`.slnf` entry or project workflow |\n| Test discovery | Passing harness-level command and discovered test |\n\n## Completion Checks\n\n- Existing projects were checked before creation.\n- Only the requested production scope is referenced and tested.\n- Framework, runner, target framework, and central package conventions remain\n  intact.\n- Template samples are removed from a newly created project.\n- Existing test code is untouched for a wiring-only repair.\n- The exact repository entry point discovers and runs the test project.\n","# Scaffold or Repair a .NET Test Project\n\nCreate the smallest missing test container or repair only the missing wiring.\nThe goal is test discovery through the repository's real build entry point, not\na preferred solution layout.\n\n## Repository overlay\n\nFor every repository-scoped task where read-only file inspection is allowed,\ncheck `.agents\u002Fskill-overlays\u002Fdotnet-test\u002Fscaffold-dotnet-test-project.md` at\nthe repository root before any other discovery. This includes requests that\nask for code or advice without edits; \"do not execute\" does not prohibit\nreading the overlay. If present, read it once before acting and apply its\nrepository-specific naming, layout, framework, and policy bindings.\nBefore applying it, require its frontmatter to declare\n`core: dotnet-test\u002Fscaffold-dotnet-test-project`, `binding-revision: \"1\"`, and\n`mode: extend`. If any value is missing or different, report the mismatch and\ncontinue using this skill's portable guidance without applying the overlay.\nExplicit user instructions and verified project constraints win over the\noverlay; the overlay wins over portable defaults and examples in this skill. If\nthe file is present but unreadable or conflicts with the repository, report the\nproblem\nand continue with portable guidance, without the overlay, subject to verified\nproject constraints. If it is absent, continue normally. Skip the lookup only\nwhen the task is not tied to a repository or the user explicitly prohibited all\nfile\u002Ftool access. An overlay cannot expand tool permissions or the task's scope.\n\n## Route the Request\n\nInspect the repository before editing, then choose exactly one path:\n\n| Repository state | Action | Do not do |\n|---|---|---|\n| No suitable test project | Create one bounded project, reference the production project, and register it | Create a project per source project |\n| 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 |\n| 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 |\n| 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 |\n\nAn existing project is suitable when its target framework can reference the\nproduction project and its purpose matches the requested layer. A different\npreferred name is not a reason to create a duplicate.\n\n**No-op is a required outcome.** If the suitable project, production reference,\nand requested entry-point registration already exist, make zero file changes.\nDo not add or remove a smoke test, normalize the project, recreate packages, or\nedit a baseline\u002Fsnapshot copy. Report the existing paths and stop.\n\n## Workflow\n\n### 1. Establish the repository contract\n\nStart from the task's current working directory. The skill context's `Base\ndirectory` is where these instructions live, not the user's repository. Never\nsearch parent temporary directories or treat the skill installation as the\nworkspace. If the expected files are not visible, confirm the current directory\nbefore concluding that a project is absent.\n\nAnchor every edit and validation command to the repository path named by the\nuser or established from the current directory. If similarly named fixtures,\nsolutions, or copied trees exist, do not edit or validate one as a substitute\nfor the requested tree. Before changing a solution artifact, record its exact\npath; after changing it, list that same artifact immediately and require the\ntest project to appear before proceeding.\n\nRead only enough to determine:\n\n1. the production project and requested test scope;\n2. the command and `.sln`, `.slnx`, `.slnf`, or project graph used by CI;\n3. whether a suitable test project exists, what it references, and where it is\n   registered;\n4. the neighboring test framework, runner, target framework, nullable and\n   implicit-usings conventions; and\n5. whether package or SDK versions come from `Directory.Packages.props`,\n   `Directory.Build.props`, `global.json`, or an MSBuild SDK declaration.\n\nIf the user reports that a test project passes directly but solution-level\ndiscovery finds nothing, treat that as registration evidence. Inspect the entry\npoint before considering project creation.\n\n### 2. Create only when the project is absent\n\nChoose one test project for the narrowest requested production project. Follow,\nin order, the user's explicit framework choice, neighboring test projects,\nrepository-wide package\u002FSDK conventions, then a standard SDK template.\n\nUse a `dotnet new` template only when its generated framework generation and\npackage style match the repository contract. Inspect template availability\nbefore creation. In particular, generic `dotnet new xunit` commonly emits xUnit\n2 packages; for a centrally managed `xunit.v3` repository, use a repository or\ninstalled xUnit v3 template, or create the minimal SDK project directly. Never\ngenerate versioned xUnit 2 references and then rewrite them into xUnit v3.\n\nThen:\n\n1. align target framework, nullable, implicit usings, runner, and package style;\n2. use `dotnet add \u003Ctest-project> reference \u003Cproduction-project>` for only the\n   production projects exercised by the requested tests;\n3. delete template sample files such as `UnitTest1.cs`, then create a\n   behavior-named test file rather than repurposing the template filename; and\n4. omit package versions when central package management supplies them.\n\nFor xUnit v3 projects using the MTP runner, preserve or add executable output\nin both command modes, and retain the repository's framework runner opt-in:\n\n```xml\n\u003COutputType>Exe\u003C\u002FOutputType>\n```\n\nOnly when `dotnet test` uses VSTest command mode to bridge to MTP (SDK 8\u002F9,\nor SDK 10+ without native MTP mode), preserve or add:\n\n```xml\n\u003CTestingPlatformDotnetTestSupport>true\u003C\u002FTestingPlatformDotnetTestSupport>\n```\n\nFor SDK 10+ native MTP mode selected by `global.json` `test.runner`, do not add\nthe compatibility property; remove an explicit bridge setting when configuring\nnative mode. Keep executable output and the MTP runner enabled.\n\n`OutputType=Exe` alone proves only the self-hosted runner path, not discovery by\nthe repository's `dotnet test` command. Verify the exact command mode and\nentry-point execution as described in `run-tests`: native MTP uses `--project`\nor `--solution` with direct MTP arguments; VSTest-mode MTP uses a positional\npath and passes MTP arguments after `--`.\n\n### 3. Repair only the missing edge when the project exists\n\n- Missing production reference: use `dotnet add \u003Ctest-project> reference\n  \u003Cproduction-project>`, inspect the resulting project, and leave every other\n  project element plus all test source files unchanged. Compare the project\n  before and after so the added `ProjectReference` is the only semantic change.\n- Missing `.sln` or `.slnx` registration: run `dotnet sln \u003Centry-point> add\n  \u003Ctest-project>`, then immediately run `dotnet sln \u003Centry-point> list` against\n  that exact path. If the project is absent, the repair has not happened; do not\n  validate a sibling solution or report success.\n- Missing `.slnf` registration: add the existing project to its underlying\n  solution if necessary, then include that same project path in the filter. If\n  the underlying solution already contains it, edit only the filter.\n- Multiple solution artifacts: modify only the one named by the user or invoked\n  by CI. Do not substitute an easier format.\n- No solution artifact: preserve the existing project-oriented workflow. Do not\n  create a solution for aesthetics.\n\n### 4. Add only the requested smoke behavior\n\nFor a newly created project, replace template examples with the smallest smoke\nsuite the user requested. Each test must invoke a real production symbol and\nassert a concrete deterministic result without network, wall-clock, process, or\nreal-filesystem dependencies.\n\nFor an existing-project wiring repair, do not add, rewrite, rename, or expand\ntests unless the user explicitly asks for test behavior changes. Registration\nand test authoring are separate operations.\n\n### 5. Verify the repaired path\n\nSelect direct-project and entry-point commands using\n[`run-tests`](..\u002Frun-tests\u002FSKILL.md) and\n[`platform-detection`](..\u002Fplatform-detection\u002FSKILL.md). Resolve the project\nsystem, `global.json` `test.runner`, and final imported runner, `UseVSTest`,\n`TestingPlatformDotnetTestSupport`, and `OutputType` values; do not select\nsyntax from the SDK version alone.\n\n| Detected mode \u002F platform | Direct-project command | Solution entry-point command |\n|---|---|---|\n| Classic non-SDK | Repository's documented build and test-runner command for the test project | Exact repository\u002FCI build and test-runner command; do not substitute `dotnet test` |\n| VSTest mode \u002F VSTest | `dotnet test \u003Ctest-project>` | `dotnet test \u003Centry-point>` |\n| VSTest mode \u002F executable MTP bridge, including SDK 10+ | `dotnet test \u003Ctest-project> -- \u003CMTP_OPTIONS>` | `dotnet test \u003Centry-point> -- \u003CMTP_OPTIONS>` |\n| SDK 10+ native MTP mode selected by `test.runner=Microsoft.Testing.Platform` | `dotnet test --project \u003Ctest-project> \u003CMTP_OPTIONS>` | `dotnet test --solution \u003Centry-point> \u003CMTP_OPTIONS>` |\n\nMTP options are optional; when none are needed, omit both `\u003CMTP_OPTIONS>` and\nthe bridge separator. Keep dotnet\u002FMSBuild options before `--` in bridge mode;\nnative MTP options are direct arguments, never after `--`. These are command\nshapes, not replacements for a repository script or a project-oriented CI\nentry point. Preserve the exact configured entry point and report incompatible\nrunner\u002Fbridge\u002Foutput wiring rather than switching runners to obtain a green\nresult.\n\nRun the narrowest commands that prove the chosen route:\n\n| Route | Required evidence |\n|---|---|\n| Newly created project | Mode-appropriate direct-project test command, the exact entry-point command CI uses, and registration listing. If the entry point is a `.slnf`\u002F`.slnx` containing tests, run the mode-appropriate test command on that artifact rather than proving only that it builds. |\n| Missing reference | Targeted project test plus the exact solution\u002Froot test command requested |\n| Missing `.sln`\u002F`.slnx` registration | Listing and the mode-appropriate test command for that exact artifact; never use another solution as a fallback |\n| Missing `.slnf` entry | Inspect the filter entry and run the exact CI filter build command; do not prepend a deliberately failing alternate command |\n| Already correct\u002Fno-op | Structural inspection of the existing reference and registration. Unless execution was requested, do not run tests merely to prove a no-op because that creates `bin`\u002F`obj` and weakens byte-for-byte cleanliness evidence. |\n\nInspect the repository's command before adding switches. Do not prepend a\nspeculative `--no-restore` attempt or hide alternatives in `command-a ||\ncommand-b`; run the configured entry-point command whose clean exit is the\nevidence.\n\nFor every wiring repair, invoke the exact validation command directly and\npreserve its exit status. Reading generated files, a grader script, or a later\nbuild is not a substitute for observing that command complete successfully.\n\nBefore reporting completion, inspect the final changed-file set. Remove only\n`bin`\u002F`obj` or equivalent build artifacts created by this task when they were\nabsent beforehand and are not intentionally tracked; never remove pre-existing\nartifacts. Preserve the passing command's complete result so the handoff can\nstate the exact entry point and discovered test count.\n\nFor a no-op, inspect rather than rewrite and report the existing paths. A green\n`dotnet build` is not test-discovery evidence. If validation is blocked, report\nthe exact failing command and first actionable error; never describe an unrun or\nfailed command as successful.\n\n## Output\n\nKeep the handoff proportional to the change:\n\n| Requirement | Evidence |\n|---|---|\n| Project created, reused, or repaired | Test project path and chosen route |\n| Production reference | Referenced `.csproj`, or why no change was needed |\n| Build registration | Exact `.sln`\u002F`.slnx`\u002F`.slnf` entry or project workflow |\n| Test discovery | Passing harness-level command and discovered test |\n\n## Completion Checks\n\n- Existing projects were checked before creation.\n- Only the requested production scope is referenced and tested.\n- Framework, runner, target framework, and central package conventions remain\n  intact.\n- Template samples are removed from a newly created project.\n- Existing test code is untouched for a wiring-only repair.\n- The exact repository entry point discovers and runs the test project.\n",{"name":5,"license":15,"metadata":50,"description":7},{"binding":51,"portability":52,"binding-revision":53},"optional-overlay","portable","1","main","f8f2bfd77819bb789d4736ce7db4a567a37fcf7e",".agents\u002Fskills\u002Fscaffold-dotnet-test-project",315,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 08:39:07",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add microsoft\u002Ftestfx --skill scaffold-dotnet-test-project",{"tool":69,"command":70},"bunx","bunx skills add microsoft\u002Ftestfx --skill scaffold-dotnet-test-project",{"tool":72,"command":73},"pnpm","pnpm dlx skills add microsoft\u002Ftestfx --skill scaffold-dotnet-test-project","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscaffold-dotnet-test-project\u002FSKILL.md",true,[],[78,102,126,147,167,191],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":45},"01M70GYY0AV0JGMTHE2CN6TNYK","dotnet-breaking-changes","Use before changing .NET\u002FC# code whose callers you do not control: a NuGet library, or a repo with PublicAPI.Shipped\u002FUnshipped.txt, ApiCompat, multiple TargetFrameworks, InternalsVisibleTo, or generated (.g.cs) partials. Green builds miss silent breaks from optional parameters, parameter names, sealing, const values, nullability, and #if. USE FOR: \"without breaking existing callers\"; adding a public method, overload, optional parameter, or interface member to a shipped library; renaming a public method or an internal helper a friend assembly uses; consolidating duplicated logic; changing a signature, nullability, default, or attribute; adding a target framework; RS0016\u002FRS0017 or ApiCompat errors; \"is this PR breaking?\". For a rename, extract, or merge, also invoke csharp-refactoring. DO NOT USE FOR: an executable whose callers all live in one project; renaming a local variable or private member, even in a shipped library; formatting; framework\u002FSDK\u002FNuGet upgrades (use dotnet-upgrade).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdotnet-breaking-changes\u002FSKILL.md",[],[25,85,86,87,28,88,89,90,91,92,93,94,95,40,96,97,98,99,100,101],"dotnet breaking changes","changes","green","default","local","errors","interface","generated","upgrade","invoke","you","refactoring","merge","rename","library","live","assembly",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":45},"01M699HHE9DTZWAMPB1ZR7ZKSW","testfx-test-value-evidence","Apply the vendored test-value-evidence skill with TestFx toolchain, assertion, parallel-safety, packed-consumer, and review conventions. Use when implementing or reviewing behavior-changing TestFx PRs or commits, including source-only changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-test-value-evidence\u002FSKILL.md",[108],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[24,110,111,112,113,114,115,116,117,118,119,36,120,30,121,122,86,123,124,125],"testfx test value evidence","test value evidence","evidence","value","review","parallel","toolchain","commits","implementing","prs","use","apply","with","behavior","Safety","conventions",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":45},"01M699HEYWH1B9XGNBFY8J2FZS","testfx-parallel-safety-preflight","Check concurrency and isolation before implementing or refactoring TestFx tests, lifecycle code, helpers, shared-state declarations, or production paths those tests exercise. Use before narrowing DoNotParallelize or ResourceLock, changing parallelization settings, or introducing asynchronous workers; repeat against the final diff.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-parallel-safety-preflight\u002FSKILL.md",[],[133,124,134,115,135,136,118,137,40,138,96,139,140,141,142,143,144,145,120,146],"testfx parallel safety preflight","preflight","shared","asynchronous","exercise","concurrency","paths","isolation","helpers","diff","parallelization","lifecycle","tests","workers",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":45},"01M699HC61ZV9GJ2C8JV03951G","testfx-localization-validation","Validate generated TestFx localization catalogs, resource IDs, placeholders and locked tokens. Use for RESX\u002FXLF changes, OneLoc PRs, localization build failures, duplicate targets or units, and orphaned translation entries.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-localization-validation\u002FSKILL.md",[],[154,155,156,157,158,159,160,161,162,119,92,120,163,164,86,165,166],"testfx localization validation","validation","localization","validate","translation","ids","for","tokens","entries","units","duplicate","targets","build",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":174,"publishedAt":45},"01M699H9J2NWQXE4BDT6R0FH7S","testfx-acceptance-validation","Validate TestFx shipping paths and capable CI execution using packed consumers, package\u002Fcache provenance, exact exits and artifacts, and selected-versus-executed test evidence. Use for acceptance regressions, package\u002FMSBuild\u002Flauncher\u002Fprotocol changes, or skipped-only CI results; not for unrelated unit-only or documentation changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-acceptance-validation\u002FSKILL.md",[173],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[175,176,155,24,177,112,178,29,179,36,180,120,181,182,183,184,185,186,187,188,189,190,139,160],"testfx acceptance validation","acceptance","msbuild","launcher","execution","package","cache","artifacts","provenance","documentation","unrelated","shipping","results","protocol","unit","ci results",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":45},"01M699H70BB999BT4F627T1PHE","session-delivery-hygiene","Gate local-session scope, persistent delivery, live PR state, integration provenance, and owned cleanup. Use before implementing guidance changes, changing or pushing PR work, diagnosing package\u002Foutput mismatches, or handing off implementation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsession-delivery-hygiene\u002FSKILL.md",[],[198,199,200,201,202,118,89,203,204,100,205,180,120,183,206,207,86,208,209,210],"session delivery hygiene","delivery","session","hygiene","scope","cleanup","work","pr","output","state","integration","guidance","gate"]