New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Migrate Xunit To Mstest

by dotnet in dotnet/skills

Convert .NET tests from xUnit.net v2/v3 to MSTest v4 while preserving VSTest or MTP.

OfficialMITAuto-check passedTesting & QA

Install Migrate Xunit To Mstest

skills CLI
$ npx skills add dotnet/skills --skill migrate-xunit-to-mstest -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install dotnet/skills migrate-xunit-to-mstest --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/dotnet/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/dotnet-test-migration/skills/migrate-xunit-to-mstest .claude/skills/migrate-xunit-to-mstest && rm -rf skills-src

Use ~/.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/

Facts

Skill name
migrate-xunit-to-mstest
GitHub stars
5.6k
Used in
1 other repo
Token cost
~3.9k tokens
SKILL.md length
1,818 words
Files
2 (incl. references)
Skills in repo
70
Repo updated
First seen
Licence
MIT

At a glance

Convert .NET tests from xUnit.net v2/v3 to MSTest v4 while preserving VSTest or MTP.

  • Works in 6 steps: Establish the baseline → Replace packages without switching runners → Perform the mechanical conversion → …
  • Replacing xunit packages
  • SKILL.md covers Scope, Workspace Contract, Response Mode and Decisions That Change the Result, plus 4 more sections
  • Calls dotnet

What it does

Migrate Xunit To Mstest is an agent skill from dotnet/skills, published by the product's own GitHub organization. Convert .NET tests from xUnit.net v2/v3 to MSTest v4 while preserving VSTest or MTP. Use for replacing xunit packages, Fact/Theory/InlineData/MemberData, assertions, IClassFixture/ICollectionFixture, ITestOutputHelper, TestContext cancellation, traits/Owner, skips, timeouts, and xUnit parallelization. Also use when a "convert xUnit to MSTest" request may already be migrated: inspect and report the no-op. Do not use for xUnit v2-to-v3, MSTest upgrades, NUnit/TUnit conversion, or runner-only VSTest-to-MTP migration.

Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/mapping-cheatsheet.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

  • Replacing xunit packages
  • Fact/Theory/InlineData/MemberData
  • IClassFixture/ICollectionFixture
  • ITestOutputHelper

Example prompts

  • “convert xUnit to MSTest”
  • “/migrate-xunit-to-mstest”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Establish the baseline
  2. Replace packages without switching runners
  3. Perform the mechanical conversion
  4. Resolve semantic mappings
  5. Preserve lifecycle, fixture scope, and parallelization
  6. Verify parity

What it can do on your machine

Read from SKILL.md and the folder at commit 1d40f95. 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

Migrate Xunit To Mstest loads about 3.9k tokens when it runs, and up to ~11k if it reads all its reference files. Until then it costs about 136 tokens; SKILL.md has 1,818 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~136
When it runs · the whole SKILL.md, loaded when a task matches
~3.9k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~11k

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 1d40f95, republished under its MIT licence (© dotnet). 1,818 words, ~3,871 tokens.

Download SKILL.mdSave it as .claude/skills/migrate-xunit-to-mstest/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
migrate-xunit-to-mstest
description
Convert .NET tests from xUnit.net v2/v3 to MSTest v4 while preserving VSTest or MTP. Use for replacing xunit packages, Fact/Theory/InlineData/MemberData, assertions, IClassFixture/ICollectionFixture, ITestOutputHelper, TestContext cancellation, traits/Owner, skips, timeouts, and xUnit parallelization. Also use when a "convert xUnit to MSTest" request may already be migrated: inspect and report the no-op. Do not use for xUnit v2-to-v3, MSTest upgrades, NUnit/TUnit conversion, or runner-only VSTest-to-MTP migration.
license
MIT

xUnit -> MSTest Migration

Convert xUnit.net v2 or v3 tests to MSTest v4 without changing the target framework or test platform. A successful migration builds, discovers the same tests, and preserves pass/fail results and execution semantics.

Scope

Use this skill only when the project contains xUnit packages or source and the user wants MSTest. If the project already uses MSTest and contains no xUnit tests, report that no framework migration is needed and make no changes.

Do not combine this framework conversion with a target-framework upgrade or VSTest/MTP migration. Complete and verify one migration before starting another.

Workspace Contract

  • Continue after skill activation. Search the current working directory for the staged project and source; never look for user files under this skill's base directory.
  • Open the literal paths returned by glob/search. If one reader or patch tool rejects a path that was just found, retry with another available tool. Do not ask the user for a path until current-workspace discovery is exhausted.
  • Classify by the requested deliverable: "convert this project" means edit, build, and test; "give me a plan" or "how would I convert it?" means answer. Do not replace execution with "please provide the files" when files are present.
  • The final response must state the source xUnit version, preserved runner, changed files, each high-risk semantic mapping applied, and actual test counts. Assertions about fixture lifetime, Owner mapping, cancellation, or parallelization must be visible in the resulting source, not only prose.

Response Mode

  • Full migration request: inspect the project, make the edits, build, and run tests. Do not stop after giving a plan.
  • Focused compile error or API question: inspect the relevant code and apply only that mapping. Do not narrate the entire workflow.
  • Unsupported target framework: stop before changing packages. MSTest v4 requires .NET 8+ or .NET Framework 4.6.2+ for test applications; offer a separately approved TFM upgrade or MSTest v3 as the intermediate target.

Decisions That Change the Result

Apply these before the mechanical mapping:

Detected stateRequired action
No xUnit package, namespace, attribute, or fixture remainsStop. Make no file changes, report that migration is unnecessary, and run the existing dotnet test command once to prove the already-MSTest project is healthy.
Source uses VSTestKeep the existing VSTest property/configuration. Prefer retaining and updating a source project's explicit Microsoft.NET.Test.Sdk pin; a repository that intentionally relies on the MSTest metapackage's transitive dependency may keep that convention. Do not introduce MTP properties.
Source uses MTPReplace xUnit-specific MTP selection with MSTest MTP configuration. Prefer MSTest.Sdk; with the metapackage, set EnableMSTestRunner=true and OutputType=Exe. Preserve native-versus-bridged command integration, and do not add <UseVSTest>true</UseVSTest> or other VSTest-only configuration.
Source relies on xUnit's default parallelizationAdd [assembly: Parallelize(Workers = 0, Scope = ExecutionScope.ClassLevel)] to a compiled .cs file when the current project has at least two independently runnable test classes. In a one-class project with no explicit parallel setting, omit it because class-level concurrency is not observable. Translate explicit CollectionBehavior or xunit.runner.json settings regardless of current class count. Before reporting completion, read the changed file back and name it in the result.

For detailed mappings and examples, search references/mapping-cheatsheet.md for constructs actually present in the project and read only the matching sections. Do not load or reproduce the whole reference.

Fast Path

For a routine project migration, converge in four phases: one batched discovery read/search, one edit pass, one dotnet test, and one concise result. Do not:

  • list a directory and then reread the same files through another tool
  • copy project files into the loaded skill or its references/ directory; those files are read-only guidance, not an editing workspace
  • try dotnet test --no-restore unless restore is already known to be current
  • run separate restore, build, and test commands when dotnet test is sufficient
  • rerun a passing test command or inspect unchanged files for confirmation

Use an existing CI/test result as the parity baseline when available. Run a new pre-edit baseline only when counts are unavailable and the migration contains data-driven tests, fixtures, skips, custom extensions, shared state, or other behavior whose parity cannot be established from source alone.

Workflow

1. Establish the baseline
  1. In one discovery pass, batch-read the test projects plus Directory.Build.props, Directory.Packages.props, global.json, and runner configuration, and search the source for the high-risk constructs below.
  2. State the detected source version:
    • xunit 2.x and related packages -> xUnit v2
    • xunit.v3 or xunit.v3.* -> xUnit v3
  3. Identify VSTest or MTP from the project and repository configuration. Use platform-detection only when the platform is ambiguous, and preserve the detected platform.
  4. Record the target frameworks and stop if MSTest v4 does not support them.
  5. If the Fast Path requires a new baseline, run the existing test command once and record discovered, passed, failed, and skipped counts.
  6. Inventory high-risk constructs before editing:
    • IClassFixture, ICollectionFixture, CollectionDefinition, custom FactAttribute/TheoryAttribute/DataAttribute
    • Assert.Throws, ThrowsAny, IsType, Record.Exception, event assertions
    • ITestOutputHelper, TestContext.Current, IAsyncLifetime
    • CollectionBehavior, xunit.runner.json, shared static or external state
2. Replace packages without switching runners

Remove xUnit packages from project files and central package files. This includes xunit*, xunit.v3.*, xunit.runner.visualstudio, YTest.MTP.XUnit2, and xUnit-specific companion packages that are being replaced.

Default to the MSTest v4 metapackage for an incremental conversion:

xml
<!-- Example pin: replace with the exact stable v4 version resolved from the configured package source. -->
<PackageReference Include="MSTest" Version="4.1.0" />

The metapackage includes Microsoft.NET.Test.Sdk, MSTest.TestAdapter, MSTest.TestFramework, and MSTest.Analyzers. When preserving VSTest, prefer retaining a source project's explicit Microsoft.NET.Test.Sdk pin and update it to a version compatible with the chosen MSTest version; this keeps runner/version compatibility reviewable. A repository that intentionally relies on the metapackage's transitive dependency may preserve that convention instead. For the example pin above, MSTest 4.1.0 requires Microsoft.NET.Test.Sdk 18.0.1+; incompatible older pins can cause NU1605.

When preserving MTP, do not carry xUnit's UseMicrosoftTestingPlatformRunner property into the MSTest project. Prefer MSTest.Sdk at the resolved version. If repository conventions require the metapackage route, set <EnableMSTestRunner>true</EnableMSTestRunner> and <OutputType>Exe</OutputType>. Retain TestingPlatformDotnetTestSupport=true only for repositories that continue to invoke MTP applications through VSTest command mode; native .NET 10+ MTP mode does not require it. When preserving VSTest with MSTest.Sdk, set <UseVSTest>true</UseVSTest>.

Do not change TargetFramework. Remove xunit.runner.json only after porting its relevant settings.

3. Perform the mechanical conversion

Apply the common rewrites first:

xUnitMSTest
no class attribute[TestClass]
[Fact][TestMethod]
[Theory] + [InlineData][TestMethod] + [DataRow]
[MemberData][DynamicData]
[Fact(Skip = "...")][TestMethod] + [Ignore("...")]
[Trait("Category", value)][TestCategory(value)]
[Trait("Owner", value)][Owner(value)]
other [Trait(key, value)][TestProperty(key, value)]
Assert.Equal / NotEqualAssert.AreEqual / AreNotEqual
Assert.True / FalseAssert.IsTrue / IsFalse
Assert.Null / NotNullAssert.IsNull / IsNotNull

Remove using Xunit; and using Xunit.Abstractions;. Add using Microsoft.VisualStudio.TestTools.UnitTesting; for the metapackage option; MSTest.Sdk supplies it as an implicit global using.

Preserve existing class inheritance. Do not mechanically seal classes.

Show full SKILL.md (751 more words)Show less
4. Resolve semantic mappings

Load the mapping cheatsheet for every high-risk construct found in Step 1. These rules are mandatory:

  • xUnit Assert.Throws<T> is exact-type and maps to MSTest Assert.ThrowsExactly<T>.
  • xUnit Assert.ThrowsAny<T> permits derived types and maps to MSTest Assert.Throws<T>.
  • xUnit Assert.IsType<T> is exact-type and maps to the generic Assert.IsExactInstanceOfType<T>; Assert.IsAssignableFrom<T> maps to the generic Assert.IsInstanceOfType<T>. When the xUnit assertion's typed return value is assigned, preserve that assignment and use the generic MSTest overload rather than a non-generic Type overload.
  • xUnit Assert.Equal on sequences compares elements. Use Assert.AreSequenceEqual on MSTest 4.3+ or CollectionAssert.AreEqual with materialized lists on earlier v4; never replace sequence equality with reference-based Assert.AreEqual.
  • [Ignore] and [Timeout] are modifiers; keep [TestMethod] so the test is discovered.
  • [DataRow] values must exactly match parameter types.
  • TestContext.Current.CancellationToken maps to an injected MSTest TestContext.CancellationToken; never replace it with CancellationToken.None or a new CancellationTokenSource.
  • Owner is a reserved VSTest property. Map [Trait("Owner", value)] to [Owner(value)], not [TestProperty("Owner", value)].
  • Assertions with no MSTest equivalent (Assert.Collection, Assert.All, Assert.Equivalent, Record.Exception, event assertions) require an explicit manual rewrite. Never delete an assertion without replacing its verification.

Apply the mechanical and semantic rewrites in one edit pass when the inventory makes the required mappings clear. Do not run an intermediate build by default; use compiler errors from final verification to drive only unresolved conversions.

5. Preserve lifecycle, fixture scope, and parallelization
  • Keep constructor setup and IDisposable/IAsyncDisposable when valid. Map IAsyncLifetime to [TestInitialize]/[TestCleanup].
  • IClassFixture<T> means one fixture instance per test class, shared by all methods in that class. Map it to a static T field created once by a static [ClassInitialize] method that accepts TestContext, and dispose it once from static [ClassCleanup]. Never use [TestInitialize]/[TestCleanup] for this mapping because that creates one fixture per test method.
  • For ICollectionFixture<T>, preserve both sharing and serialization. Prefer a static Lazy<T> helper used by each member class; add [DoNotParallelize] only when the source collection disabled parallelization. Use assembly initialization only when the fixture is genuinely assembly-wide.
  • Replace ITestOutputHelper with constructor-injected or property-based MSTest TestContext, and replace each _output.WriteLine(...) call with the corresponding TestContext.WriteLine(...). In the final result, name both the TestContext injection/property and the WriteLine mapping explicitly; "migrated output" is not enough to demonstrate parity.

xUnit runs classes in parallel by default; MSTest runs them serially. When the current project has two or more independently runnable test classes, preserve that effective behavior with:

csharp
[assembly: Parallelize(Workers = 0, Scope = ExecutionScope.ClassLevel)]

For a one-class project with no explicit xUnit parallel setting, do not add an assembly policy: there is no class-level concurrency to preserve. Always translate explicit CollectionBehavior or xunit.runner.json settings. Never use ExecutionScope.MethodLevel to emulate xUnit. Before applying a fixture-scope or parallelization decision, state what the source shared or serialized and how the target preserves it.

6. Verify parity
  1. Run tests once with the same platform, filter, and configuration used for the baseline. dotnet test builds by default; run a separate build only when needed to isolate a compilation failure.
  2. Compare discovered, passed, failed, and skipped counts.
  3. Investigate every difference before declaring completion:
    • missing cases -> discovery attributes, DynamicData, or DataRow literal types
    • changed exception behavior -> exact-vs-derived assertion mapping
    • shared-state failures or large duration changes -> fixture scope and parallelization
    • silently skipped tests -> missing [TestMethod] or incorrect runtime-skip conversion
  4. Confirm no xUnit package, namespace, attribute, runner configuration, or fixture interface remains unless explicitly documented for manual follow-up.
  5. After the final passing test, read back each changed file that implements a high-risk mapping, plus any runner or parallelization configuration. In the result, name the file and the exact target APIs that implement its lifecycle, data, skip, output, assertion, fixture-scope, or parallelization behavior. Preserve type arguments and member names such as [ClassInitialize], TestContext.WriteLine, and Assert.IsExactInstanceOfType<T>; generic claims such as "converted attributes" or "migrated output" are not evidence of parity.

Keep the final response concise and outcome-focused:

  • Changed: name the files and exact high-risk mappings applied.
  • Verified: give the final test command and discovered/passed/failed/skipped counts.
  • Preserved: state the unchanged target framework and test platform, plus any fixture or parallelization scope decision.
  • Remaining: identify manual follow-up, or say none.

Completion Criteria

  • Current xUnit version and test platform were identified
  • xUnit packages and source constructs were converted
  • Target framework and test platform stayed unchanged
  • Fixture scope and effective parallelization decisions are explicit, including justified omission when concurrency is not observable
  • Build succeeds
  • Test discovery and result counts match the baseline
  • Any unsupported custom extension point is called out rather than approximated

Follow-up

Run migrate-vstest-to-mtp separately if the user also wants MTP. Use writing-mstest-tests only after parity is established to polish the converted MSTest code.

© 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-migration/skills/migrate-xunit-to-mstest of dotnet/skills.

  • SKILL.md
  • references/mapping-cheatsheet.md

Open the folder on GitHubat commit 1d40f95

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

Migrate Xunit To Mstest 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.

Migrate Xunit To Mstest compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Migrate Xunit To Mstest this skilldotnet/skills5.6k1 repos~3.9kAutomated safety check: PassMIT
ScottPlot Test RunnerScottPlot/ScottPlot6.8k—~308Automated safety check: PassMIT
Aspire Integration TestingDevBetterCom/DevBetterWeb1572 repos~2.3kAutomated safety check: PassNone
New Event Sourceaws/aws-lambda-dotnet1.7k—~3kAutomated safety check: PassApache-2.0
Platform Detectionmicrosoft/testfx1k2 repos~3.3kAutomated safety check: PassMIT
Vstest Build Testmicrosoft/vstest969—~1.9kAutomated safety check: PassMIT

Similar skills

  • 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…

    6.8k GitHub stars~308 tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • Aspire Integration Testing

    DevBetterCom/DevBetterWeb

    Write integration tests using .NET Aspire's testing facilities with xUnit.

    157 GitHub starsUsed in 2 repos~2.3k tokens
    Testing & QAAuto-check passed

  • New Event Source

    aws/aws-lambda-dotnet

    Official

    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…

    1.7k GitHub stars~3k tokensUpdated today
    Testing & QAAuto-check passed

  • Platform Detection

    microsoft/testfx

    Official

    Identify a .NET project's test platform, framework, command mode, and SDK-style vs classic project system.

    1k GitHub starsUsed in 2 repos~3.3k tokens
    Testing & QAAuto-check passed

  • Vstest Build Test

    microsoft/vstest

    Official

    Build, test, and validate changes in the vstest repository. An agent skill from microsoft/vstest.

    969 GitHub stars~1.9k tokensUpdated today
    Testing & QAAuto-check passed

  • Coverage Analysis

    runceel/ReactiveProperty

    Automated, project-wide code coverage and CRAP (Change Risk Anti-Patterns) score analysis for .NET projects with existing unit tests.

    944 GitHub stars~5.9k tokensUpdated 1 mo ago
    Testing & QAAuto-check: warnings

More from dotnet/skills

All 70 skills in this repo

  • Apple Crash Log .NET Symbolication

    dotnet/skills

    Official

    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.

    5.6k GitHub starsUsed in 1 repo~2.4k tokens
    Auto-check passed

  • Analyzing .NET Performance

    dotnet/skills

    Official

    Scans C# and .NET code for about 50 performance anti-patterns and reports prioritized findings with concrete fixes, at a scan depth you choose.

    5.6k GitHub starsUsed in 3 repos~3.1k tokens
    Auto-check passed

  • Android Tombstone Symbolication

    dotnet/skills

    Official

    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.

    5.6k GitHub starsUsed in 1 repo~2.1k tokens
    Auto-check passed

  • Microbenchmarking

    dotnet/skills

    Official

    Activate this skill when BenchmarkDotNet (BDN) is involved in the task — creating, running, configuring, or reviewing BDN benchmarks.

    5.6k GitHub starsUsed in 3 repos~3.3k tokens
    Auto-check passed

  • .NET Native AOT Compatibility

    dotnet/skills

    Official

    Makes .NET projects compatible with Native AOT and trimming by resolving IL trim and AOT analyzer warnings through annotations rather than suppressions.

    5.6k GitHub starsUsed in 2 repos~4.2k tokens
    Auto-check passed

  • .NET Crash Dump Collection

    dotnet/skills

    Official

    Configures automatic crash dumps or captures dumps from running processes for modern .NET apps on Linux, macOS and Windows, including Docker and Kubernetes.

    5.6k GitHub starsUsed in 2 repos~1.1k tokens
    Auto-check passed

Works with

Categories

Questions about Migrate Xunit To Mstest

What does Migrate Xunit To Mstest do?

Convert .NET tests from xUnit.net v2/v3 to MSTest v4 while preserving VSTest or MTP. Migrate Xunit To Mstest is an agent skill from dotnet/skills, published by the product's own GitHub organization.net v2/v3 to MSTest v4 while preserving VSTest or MTP.

When should I use Migrate Xunit To Mstest?

Migrate Xunit To Mstest fits situations like: replacing xunit packages; fact/Theory/InlineData/MemberData; IClassFixture/ICollectionFixture; ITestOutputHelper.

How do I install Migrate Xunit To Mstest in Claude Code?

Run `npx skills add dotnet/skills --skill migrate-xunit-to-mstest -a claude-code`. Or copy the skill folder (plugins/dotnet-test-migration/skills/migrate-xunit-to-mstest in dotnet/skills) into .claude/skills/migrate-xunit-to-mstest in your project. Claude Code loads it when a task matches its description.

How do I install Migrate Xunit To Mstest in Codex?

Run `npx skills add dotnet/skills --skill migrate-xunit-to-mstest -a codex`. Or copy the skill folder (plugins/dotnet-test-migration/skills/migrate-xunit-to-mstest in dotnet/skills) into .agents/skills/migrate-xunit-to-mstest in your project. Codex loads it when a task matches its description.

Can I use Migrate Xunit To Mstest 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 migrate-xunit-to-mstest -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/migrate-xunit-to-mstest, .gemini/skills/migrate-xunit-to-mstest, .github/skills/migrate-xunit-to-mstest and .opencode/skills/migrate-xunit-to-mstest in your project.

What does Migrate Xunit To Mstest need to run?

Going by SKILL.md and its folder, Migrate Xunit To Mstest needs the command-line tools its instructions call (dotnet).

Does Migrate Xunit To Mstest 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 Migrate Xunit To Mstest 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 Migrate Xunit To Mstest use?

Migrate Xunit To Mstest 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 Migrate Xunit To Mstest use?

About 3.9k tokens (SKILL.md is roughly 15k 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 7k tokens, read only when the agent opens those files.

What are the alternatives to Migrate Xunit To Mstest?

Skills that share tags, products or a category with Migrate Xunit To Mstest: ScottPlot Test Runner (ScottPlot/ScottPlot, 6.8k stars), Aspire Integration Testing (DevBetterCom/DevBetterWeb, 157 stars), New Event Source (aws/aws-lambda-dotnet, 1.7k stars) and Platform Detection (microsoft/testfx, 1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Migrate Xunit To Mstest?

dotnet (a GitHub organization, an official publisher) maintains it in dotnet/skills, which has 5,594 GitHub stars. The repository holds 70 skills in this directory. The repository was last updated on October 9, 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.