Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dotnet/platform-detection
Reference data for detecting the test platform (VSTest vs Microsoft.Testing.Platform) and test framework (MSTest, xUnit, NUnit, TUnit) from project files. DO NOT USE directly — loaded by run-tests, mtp-hot-reload, and migrate-vstest-to-mtp when they need detection logic.
Passed 19 of 22 test cases with the skill, and 11 of 22 without it.
and 10 more in the full report
9 fixed11 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our repository project references TUnit 0.1.500 and OutputType is Exe. Identify the test platform and framework. Output the verdict first, then an evidence sentence.
| Checked | Without skill | With skill |
|---|---|---|
| The response identifies the test platform as MTP. | Passed | Passed |
| The response identifies TUnit as an MTP-only framework. | Missed | Passed |
The instructions your model reads when the skill loads.
Determine which test platform (VSTest or Microsoft.Testing.Platform) and which test framework (MSTest, xUnit, NUnit, TUnit) a project uses.
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.
test cases passed, vs 11 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.