New Event Source
aws/aws-lambda-dotnet
Add a new AWS event source attribute (e.g., Kinesis, Kafka, MQ) to the Lambda .NET Annotations framework, including the attribute class, source generator integration, CloudFormation writer, unit…
Identify a .NET project's test platform, framework, command mode, and SDK-style vs classic project system.
Install Platform Detection
$ npx skills add dotnet/skills --skill platform-detection -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install dotnet/skills platform-detection --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/dotnet-test/skills/platform-detection .claude/skills/platform-detection && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "platform-detection" agent skill from https://github.com/dotnet/skills/tree/main/plugins/dotnet-test/skills/platform-detection into .claude/skills/platform-detection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "platform-detection", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/dotnet/skills/tree/main/plugins/dotnet-test/skills/platform-detectionType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add dotnet/skills --skill platform-detection -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install dotnet/skills platform-detection --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/plugins/dotnet-test/skills/platform-detection .agents/skills/platform-detection && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "platform-detection" agent skill from https://github.com/dotnet/skills/tree/main/plugins/dotnet-test/skills/platform-detection into .agents/skills/platform-detection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "platform-detection", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add dotnet/skills --skill platform-detection -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install dotnet/skills platform-detection --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/plugins/dotnet-test/skills/platform-detection .cursor/skills/platform-detection && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "platform-detection" agent skill from https://github.com/dotnet/skills/tree/main/plugins/dotnet-test/skills/platform-detection into .cursor/skills/platform-detection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "platform-detection", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/dotnet/skills.git --path plugins/dotnet-test/skills/platform-detection--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add dotnet/skills --skill platform-detection -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install dotnet/skills platform-detection --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/plugins/dotnet-test/skills/platform-detection .gemini/skills/platform-detection && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "platform-detection" agent skill from https://github.com/dotnet/skills/tree/main/plugins/dotnet-test/skills/platform-detection into .gemini/skills/platform-detection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "platform-detection", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install dotnet/skills platform-detectionInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add dotnet/skills --skill platform-detection -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/plugins/dotnet-test/skills/platform-detection .github/skills/platform-detection && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "platform-detection" agent skill from https://github.com/dotnet/skills/tree/main/plugins/dotnet-test/skills/platform-detection into .github/skills/platform-detection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "platform-detection", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add dotnet/skills --skill platform-detection -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install dotnet/skills platform-detection --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/plugins/dotnet-test/skills/platform-detection .opencode/skills/platform-detection && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "platform-detection" agent skill from https://github.com/dotnet/skills/tree/main/plugins/dotnet-test/skills/platform-detection into .opencode/skills/platform-detection/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "platform-detection", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
platform-detection- GitHub stars
- 5.6k
- Used in
- 1 other repo
- Token cost
- ~3.3k tokens
- SKILL.md length
- 1,589 words
- Files
- 2 (incl. references)
- Skills in repo
- 91
- Repo updated
- First seen
- Licence
- MIT
At a glance
Identify a .NET project's test platform, framework, command mode, and SDK-style vs classic project system.
- Works in 4 steps: Follow the import graph and conditions.… → Record the final value and its winning… → Treat Directory.Packages.props as… → …
- The user asks to run/filter tests
- SKILL.md covers Response contract, Detecting the project system, Detecting the test framework and Detecting the executed test…
- Calls dotnet
What it does
Platform Detection is an agent skill from dotnet/skills, published by the product's own GitHub organization. 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…
Its SKILL.md is about 3.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/command-mode.md`).
It sits in Testing & QA, covering Unit testing. It works with .NET. The repository describes itself as: Repository for skills to assist AI coding agents with .NET and C. The licence is MIT.
When your agent uses it
- The user asks to run/filter tests
- Test-command/filter errors
- Use run-tests directly
Example prompts
- “which test platform/framework?”
- “VSTest or MTP?”
- “what runner does this project use?”
- “/platform-detection”
Workflow steps
4 steps, taken from the first numbered list in SKILL.md.
- Follow the import graph and conditions. A later applicable assignment wins.
- Record the final value and its winning source for UseVSTest, the framework
- Treat Directory.Packages.props as version evidence unless it also contains
- Never infer a property from package presence. A package or SDK default counts
What it can do on your machine
Read from SKILL.md and the folder at commit 8d670fa. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
dotnet
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Platform Detection loads about 3.3k tokens when it runs, and up to ~3.6k if it reads all its reference files. Until then it costs about 189 tokens; SKILL.md has 1,589 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from dotnet/skills at commit 8d670fa, republished under its MIT licence (© dotnet). 1,589 words, ~3,323 tokens.
Download SKILL.mdSave it as
.claude/skills/platform-detection/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.- 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.jsonis context, not a platform selector. Claim thatglobal.jsonselects VSTest or native MTP only when itstest.runnersetting actually does so. - If
UseVSTest=trueis decisive, say that directly. Do not speculate about an absenttest.runneror 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:
- Follow the import graph and conditions. A later applicable assignment wins.
Directory.Build.propsis normally imported before the project body, so an unconditional project assignment normally overrides it; later.targetscan override the project again. - Record the final value and its winning source for
UseVSTest, the framework runner selector,TestingPlatformDotnetTestSupport, andOutputType. - Treat
Directory.Packages.propsas version evidence unless it also contains relevant properties. Resolve package/SDK versions before applying version-dependent defaults. - Never infer a property from package presence. A package or SDK default counts only when that resolved version actually supplies it and no later assignment overrides it.
Detecting the project system
Classify the project before selecting a CLI:
- Root
Sdkattribute or<Sdk>declaration: SDK-style. ToolsVersion,Microsoft.Common.props/Microsoft.CSharp.targetsimports, explicit<Reference>and<Compile Include>items: classic non-SDK.packages.config: classic NuGet dependency management.
Classic projects can still use VSTest-compatible adapters, but dotnet test is
not automatically a valid invocation. Preserve repository scripts/CI commands,
commonly MSBuild followed by vstest.console.exe. Mention MSTest.exe only
when repository configuration or documentation establishes that legacy runner.
Detecting the test framework
Read the .csproj, adjacent packages.config, and
Directory.Build.props / Directory.Packages.props and look for:
| Package or SDK reference | Framework |
|---|---|
MSTest metapackage, <Project Sdk="MSTest.Sdk[/version]">, 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) |
In classic projects, package IDs and versions may appear only in
packages.config, while the project contains assembly <Reference> elements
with HintPath values. Use both sources.
Show full SKILL.md (715 more words)Show less
Detecting the executed test platform
If the user explicitly requests dotnet test mode, read
references/command-mode.md before answering.
Do not load that reference or mention command mode for a
platform/framework-only request.
For an SDK 8/9 request that explicitly asks about command mode and has no
effective bridge, state all three facts in one causal sentence: the runner makes
the project MTP-capable, dotnet test remains in VSTest mode, and the missing
bridge means VSTest actually executes the tests. Mention that native MTP command
mode starts with SDK 10 only when it helps explain that result.
When execution is permitted and neither the prompt nor global.json identifies
the SDK, run dotnet --version once. For read-only identification requests that
prohibit execution, do not probe the installed SDK; use repository facts and
state any necessary SDK assumption.
After resolving final property values, classify in this order:
- Final
UseVSTest=trueselects VSTest. Ifglobal.jsonsimultaneously selects native MTP command mode, reportPlatform: unavailablebecause the command mode and project opt-out conflict. - A native-MTP selection in
global.jsonexecutes a compatible MTP application with finalOutputType=Exeon MTP. A VSTest-only, library-output, or opted-out project is unavailable. - On SDK 8/9, an enabled MTP runner plus final
TestingPlatformDotnetTestSupport=trueplus finalOutputType=Exeexecutes on MTP. - If the runner is enabled but the bridge is absent or false, a dual-capable
MSTest, NUnit, or xUnit project remains on VSTest: the runner establishes MTP
capability, but SDK 8/9
dotnet testcannot reach it and the VSTest adapter executes the tests instead. If the bridge is true but no runner is enabled, the project also remains on VSTest. - A runner and bridge with non-executable output is incomplete and unavailable. An MTP-only framework that cannot be reached by the selected SDK path is also unavailable, not VSTest.
Keep each signal's role exact:
- The runner property selects the test application.
TestingPlatformDotnetTestSupport=truelets SDK 8/9dotnet testreach that application.OutputType=Exesupplies the executable host shape. It does not select or enable MTP.
Do not confuse the MSTest metapackage with the MSTest.Sdk project SDK.
PackageReference Include="MSTest" plus EnableMSTestRunner=true enables the
MSTest MTP runner, but it does not implicitly set
TestingPlatformDotnetTestSupport.
MSTest.Sdk enables the MTP runner by default. Check its resolved version and
evaluated properties for bridge behavior: version 3.8 supplies
TestingPlatformDotnetTestSupport unless a later assignment overrides it,
while newer SDKs on .NET 10 may expect native MTP mode instead.
<UseVSTest>true</UseVSTest> opts back into VSTest.
| Signal | Meaning |
|---|---|
<Project Sdk="MSTest.Sdk..."> with no UseVSTest | MTP application; inspect the resolved SDK version and evaluated bridge property |
MSTest metapackage + <EnableMSTestRunner>true> | MTP runner enabled; does not imply the VSTest-to-MTP bridge |
<UseMicrosoftTestingPlatformRunner>true | Deciding xUnit runner-selection signal |
<EnableMSTestRunner>true> / <EnableNUnitRunner>true> | Deciding MSTest/NUnit runner-selection signal |
TestingPlatformDotnetTestSupport=true | Execution prerequisite for a VSTest-to-MTP bridge, not the runner-selection signal |
Microsoft.Testing.Platform package | MTP-capable application; not decisive by itself |
TUnit | MTP-only framework |
Final evaluated <OutputType>Exe</OutputType> | Required executable host shape for package-based MTP applications |
Microsoft.NET.Test.Sdk alone is not decisive; it can remain for compatibility
in an MTP-enabled project. When an explicit override decides the result, name
the final override and its source, not the superseded default.
When a runner-selection property competes with Microsoft.NET.Test.Sdk, say
that the runner property selects MTP and Microsoft.NET.Test.Sdk does not
select or imply VSTest. It may remain as compatibility support, but that is
secondary. TestingPlatformDotnetTestSupport=true is a bridge prerequisite, not
the runner-selection signal; never say that this property alone enables the
bridge. For a request asking which single signal decides, stop there. Omit
bridge or host-shape prerequisites when the configuration is complete, and add
them only when needed to explain why the selected runner cannot execute.
Likewise, when an enabled runner is overridden or unreachable, state both axes
causally: the runner property makes the project MTP-capable, but the final
UseVSTest/bridge/output setting determines which platform actually executes.
Name the runner selector before using a package reference only to identify the
framework.
Use causal evidence, not a bag of signals. For example:
Platform: MTP
Framework: NUnit
Directory.Build.props supplies final EnableNUnitRunner=true and
TestingPlatformDotnetTestSupport=true, so NUnit executes on MTP.For an incompatible configuration, give one minimal alignment choice after the verdict without modifying files: either select the project's configured platform globally or remove the project opt-out to use the globally selected platform.
Conditional and per-target-framework properties
Evaluate runner and bridge properties for each target framework. If conditions
produce different executed platforms, report each target explicitly (for
example, net8.0: VSTest, net9.0: MTP) rather than collapsing the project to
one global platform.
© dotnet, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 1 other file (references) in plugins/dotnet-test/skills/platform-detection of dotnet/skills.
- SKILL.md
- references/command-mode.md
Open the folder on GitHubat commit 8d670fa
Used in 1 other repository
We found 2 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in dotnet/skills, which our catalogue first saw on October 7, 2026.
Compare with similar skills
Platform Detection next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Platform Detection this skilldotnet/skills | 5.6k | 1 repos | ~3.3k | Automated safety check: Pass | MIT | |
| New Event Sourceaws/aws-lambda-dotnet | 1.7k | — | ~3k | Automated safety check: Pass | Apache-2.0 | |
| ScottPlot Test RunnerScottPlot/ScottPlot | 6.8k | — | ~308 | Automated safety check: Pass | MIT | |
| Aspire Integration TestingDevBetterCom/DevBetterWeb | 157 | 2 repos | ~2.3k | Automated safety check: Pass | None | |
| Vstest Build Testmicrosoft/vstest | 969 | — | ~1.9k | Automated safety check: Pass | MIT | |
| Coverage Analysisrunceel/ReactiveProperty | 944 | — | ~5.9k | Automated safety check: Warn | MIT |
Similar skills
- Official
ScottPlot Test Runner
ScottPlot/ScottPlot
Run or add ScottPlot 5 tests. Use for unit-test and cookbook-test work; unless explicitly asked otherwise, restrict manual test execution to the Unit Tests…
Aspire Integration Testing
DevBetterCom/DevBetterWeb
Write integration tests using .NET Aspire's testing facilities with xUnit.
- Official
Vstest Build Test
microsoft/vstest
Build, test, and validate changes in the vstest repository. An agent skill from microsoft/vstest.
Coverage Analysis
runceel/ReactiveProperty
Automated, project-wide code coverage and CRAP (Change Risk Anti-Patterns) score analysis for .NET projects with existing unit tests.
Unit Testing
OpenCoreMMO/OpenCoreMMO
Write, fix, or review NeoServer unit tests using xUnit and FluentAssertions.
More from dotnet/skills
All 91 skills in this repo- Official
Apple Crash Log .NET Symbolication
dotnet/skills
Resolves .NET runtime frames in Apple .ips crash logs to function names, source files and line numbers using dSYM symbols, atos and the Microsoft symbol server.
- Official
Android Tombstone Symbolication
dotnet/skills
Resolves native crash frames from .NET Android tombstones to function names, source files and line numbers using BuildIds, Microsoft's symbol server and llvm-symbolizer.
- Official
Analyzing .NET Performance
dotnet/skills
Scans C# and .NET code for about 50 performance anti-patterns and reports prioritized findings with concrete fixes, at a scan depth you choose.
- Official
Find Untested Sources
dotnet/skills
Statically pairs source files with test files to list code that no test references, using Roslyn for C# or tree-sitter for many languages, with no build.
- Official
Microbenchmarking
dotnet/skills
Activate this skill when BenchmarkDotNet (BDN) is involved in the task — creating, running, configuring, or reviewing BDN benchmarks.
- Official
.NET Native AOT Compatibility
dotnet/skills
Makes .NET projects compatible with Native AOT and trimming by resolving IL trim and AOT analyzer warnings through annotations rather than suppressions.
Related
Works with
Categories
Questions about Platform Detection
What does Platform Detection do?
Identify a .NET project's test platform, framework, command mode, and SDK-style vs classic project system. Platform Detection is an agent skill from dotnet/skills, published by the product's own GitHub organization.NET project's test platform, framework, command mode, and SDK-style vs classic project system.
When should I use Platform Detection?
Platform Detection fits situations like: the user asks to run/filter tests; test-command/filter errors; use run-tests directly.
How do I install Platform Detection in Claude Code?
Run `npx skills add dotnet/skills --skill platform-detection -a claude-code`. Or copy the skill folder (plugins/dotnet-test/skills/platform-detection in dotnet/skills) into .claude/skills/platform-detection in your project. Claude Code loads it when a task matches its description.
How do I install Platform Detection in Codex?
Run `npx skills add dotnet/skills --skill platform-detection -a codex`. Or copy the skill folder (plugins/dotnet-test/skills/platform-detection in dotnet/skills) into .agents/skills/platform-detection in your project. Codex loads it when a task matches its description.
Can I use Platform Detection in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add dotnet/skills --skill platform-detection -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/platform-detection, .gemini/skills/platform-detection, .github/skills/platform-detection and .opencode/skills/platform-detection in your project.
What does Platform Detection need to run?
Going by SKILL.md and its folder, Platform Detection needs the command-line tools its instructions call (dotnet).
Does Platform Detection access the network?
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Is Platform Detection safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Platform Detection use?
Platform Detection is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Platform Detection use?
About 3.3k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 238 tokens, read only when the agent opens those files.
What are the alternatives to Platform Detection?
Skills that share tags, products or a category with Platform Detection: New Event Source (aws/aws-lambda-dotnet, 1.7k stars), ScottPlot Test Runner (ScottPlot/ScottPlot, 6.8k stars), Aspire Integration Testing (DevBetterCom/DevBetterWeb, 157 stars) and Vstest Build Test (microsoft/vstest, 969 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Platform Detection?
dotnet (a GitHub organization, an official publisher) maintains it in dotnet/skills, which has 5,568 GitHub stars. The repository holds 91 skills in this directory. The repository was last updated on October 7, 2026.
Source: dotnet/skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.