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.
npx skills add https://github.com/dotnet/skills --skill platform-detection
Determine which test platform (VSTest or Microsoft.Testing.Platform) and which test framework (MSTest, xUnit, NUnit, TUnit) a project uses.
Detection files to always check (in order): global.json → .csproj → Directory.Build.props → Directory.Packages.props
Read the .csproj file and Directory.Build.props / Directory.Packages.props (for centrally managed dependencies) and look for:
| Package or SDK reference | Framework |
|--------------------------|-----------|
| MSTest (metapackage, recommended) or <Sdk Name="MSTest.Sdk"> | MSTest |
| MSTest.TestFramework + MSTest.TestAdapter | MSTest (also valid for v3/v4) |
| xunit, xunit.v3, xunit.v3.mtp-v1, xunit.v3.mtp-v2, xunit.v3.core.mtp-v1, xunit.v3.core.mtp-v2 | xUnit |
| NUnit + NUnit3TestAdapter | NUnit |
| TUnit | TUnit (MTP only) |
The detection logic depends on the .NET SDK version. Run dotnet --version to determine it.
On .NET 10+, the global.json test.runner setting is the authoritative source:
global.json contains "test": { "runner": "Microsoft.Testing.Platform" } → MTPglobal.json has "runner": "VSTest", or no test section exists → VSTest> Important: On .NET 10+, <TestingPlatformDotnetTestSupport> alone does not switch to MTP. The global.json runner setting takes precedence. If the runner is VSTest (or unset), the project uses VSTest regardless of TestingPlatformDotnetTestSupport.
On older SDKs, check these signals in priority order:
1. Check the <TestingPlatformDotnetTestSupport> MSBuild property. Look in the .csproj, Directory.Build.props, and Directory.Packages.props. If set to true in any of these files, the project uses MTP.
> Critical: Always read Directory.Build.props and Directory.Packages.props if they exist. MTP properties are frequently set there instead of in the .csproj, so checking only the project file will miss them.
2. Check project-level signals:
| Signal | Platform |
|--------|----------|
| <Sdk Name="MSTest.Sdk"> as project SDK | MTP by default |
| <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> | MTP runner (xUnit) |
| <EnableMSTestRunner>true</EnableMSTestRunner> | MTP runner (MSTest) |
| <EnableNUnitRunner>true</EnableNUnitRunner> | MTP runner (NUnit) |
| Microsoft.Testing.Platform package referenced directly | MTP |
| TUnit package referenced | MTP (TUnit is MTP-only) |
> Note: The presence of Microsoft.NET.Test.Sdk does not necessarily mean VSTest. Some frameworks (e.g., MSTest) pull it in transitively for compatibility, even when MTP is enabled. Do not use this package as a signal on its own — always check the MTP signals above first.
> Key distinction: VSTest is the classic platform that uses vstest.console under the hood. Microsoft.Testing.Platform (MTP) is the newer, faster platform. Both can be invoked via dotnet test, but their filter syntax and CLI options differ.
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when implementing any feature or bugfix, before writing implementation code
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Expert guidance for systematic backtesting of trading strategies. Use when developing, testing, stress-testing, or validating quantitative trading strategies. Covers "beating ideas to death" methodology, parameter robustness testing, slippage modeling, bias prevention, and interpreting backtest results. Applicable when user asks about backtesting, strategy validation, robustness testing, avoiding overfitting, or systematic trading development.
Cloud laboratory platform for automated protein testing and validation. Use when designing proteins and needing experimental validation including binding assays, expression testing, thermostability measurements, enzyme activity assays, or protein sequence optimization. Also use for submitting experiments via API, tracking experiment status, downloading results, optimizing protein sequences for better expression using computational tools (NetSolP, SoluProt, SolubleMPNN, ESM), or managing protein design workflows with wet-lab validation.
This skill should be used for time series machine learning tasks including classification, regression, clustering, forecasting, anomaly detection, segmentation, and similarity search. Use when working with temporal data, sequential patterns, or time-indexed observations requiring specialized algorithms beyond standard ML approaches. Particularly suited for univariate and multivariate time series analysis with scikit-learn compatible APIs.
Take dotnet/platform-detection from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.