/platform-detection

name: platform-detection
description: >-
  Identify a .NET project's test platform, framework, command mode, and
  SDK-style vs classic project system. Use only for "which test
  platform/framework?", "VSTest or MTP?", or "what runner does this project
  use?", including bridge settings, UseVSTest opt-outs, and incompatible or
  conflicting VSTest/MTP configuration. Resolves global.json, project,
  packages.config, Directory.Build.props, and Directory.Packages.props
  precedence for MSTest/xUnit/NUnit/TUnit. DO NOT USE when the user asks to
  run/filter tests or for commands, flags, TRX/dumps, or test-command/filter
  errors; use run-tests directly.
  Do not route hot-reload or migration requests here as the entry skill;
  mtp-hot-reload may use this skill internally for platform detection.
license: MIT

Test Platform and Framework Detection

Determine **which test platform** (VSTest or Microsoft.Testing.Platform) and **which test framework** (MSTest, xUnit, NUnit, TUnit) a project uses.

Response contract

Honor the user's requested labels and order exactly, substituting the actual classification for every placeholder. Start with the verdict: never put a heading, scratch analysis, tool syntax, or an echoed template before it. Follow with one concise evidence sentence naming the repository facts needed to justify every requested classification. When `Framework` is requested, name the package or project SDK that identifies it. Use a second sentence only for a conflict, an incomplete configuration, or target-framework-specific differences.

`Platform` means the platform that actually executes tests: **VSTest** or **MTP**. If conflicting or incomplete configuration prevents execution, report it as unavailable rather than inventing a successful platform.

Never classify the executed platform from `global.json` `test.runner` alone. That setting selects `dotnet test` command mode; even an explicit `VSTest` value can bridge to an executable MTP application. Continue through the project runner, bridge, and output-shape signals before writing `Platform:`.

Apply this scope gate before drafting the evidence:

| User asks for | Evidence to include | Omit | |---------------|---------------------|------| | Platform and framework | Final runner selector and its winning source; package or project SDK identifying the framework; when needed, the property that makes it executable | Command mode; common SDK facts; `OutputType` unless it is missing or conflicting | | The single deciding signal | That runner-selection property, why its source wins, and why a competing package does not select or imply VSTest; still name the package or project SDK identifying a requested framework | Bridge, `OutputType`, SDK mode, and unrelated prerequisites when the configuration is complete | | Platforms per target framework | Only the conditional final values that differ by target | Common properties and project-wide SDK commentary | | Explicit opt-out | Final `UseVSTest` value and its winning source | Superseded defaults unless they create a conflict | | `dotnet test` mode | The separate command-mode and executed-platform classifications | None of the requested axes |

If the requested labels omit `dotnet test mode`, do not state or explain command mode anywhere in the response. An exact bridge property may still be decisive platform evidence, but do not turn it into SDK or CLI-mode commentary. When the user asks which single signal decides between an explicit runner property and `Microsoft.NET.Test.Sdk`, the evidence sentence must say both that the runner property selects MTP and that `Microsoft.NET.Test.Sdk` does not select or imply VSTest.

When import precedence decides a property, state why the winning source wins (for example, it is imported later or its condition applies), not merely that it contains the final value or overrides another assignment.

Keep the explanation on the requested axis:

• An SDK version pin in `global.json` is context, not a platform selector. Claim

that `global.json` selects VSTest or native MTP only when its `test.runner` setting actually does so.

• If `UseVSTest=true` is decisive, say that directly. Do not speculate about an

absent `test.runner` or describe SDK pinning as an additional platform choice.

• If command mode was not requested, do not add it, even when it was needed

internally to determine the executed platform.

When a classic-project request also asks for the command family, add a direct line such as `Command family: MSBuild + vstest.console.exe`; do not turn it into an optional alternative or add an unnecessary build qualifier.

For a file-backed request, enumerate the following configuration names once, then read every relevant file that is present in one batched operation: `global.json`, `.csproj`, `packages.config`, `Directory.Build.props`, `Directory.Build.targets`, `Directory.Packages.props`, and explicit imported `.props` / `.targets`. A setting absent from the project file may be defined by an import, so never infer its final value from the `.csproj` alone. Do not search the web or inspect unrelated files when repository configuration is sufficient.

Resolve properties in the actual MSBuild import order, not with a fixed "project beats props" rule. For every applicable target framework:

1. Follow the import graph and conditions. A later applicable assignment wins. `Directory.Build.props` is normally imported before the project body, so an unconditional project assignment normally overrides it; later `.targets` can override the project again. 2. Record the final value and its winning source for `UseVSTest`, the framework runner selector, `TestingPlatformDotnetTestSupport`, and `OutputType`. 3. Treat `Directory.Packages.props` as version evidence unless it also contains relevant properties. Resolve package/SDK versions before applying version-dependent defaults. 4. Never infer a property from package presence. A package or SDK defa