.NET Agent Skills

repository·main·Indexed 26 days ago

https://github.com/dotnet/skills

A curated set of plugins and agents designed to enhance AI coding agents (such as Copilot, Claude Code, and Cursor) for the .NET ecosystem. Includes the `skill-validator` tool for static analysis via the `check` subcommand and LLM-based evaluation via the `evaluate` subcommand to determine if agent skills add value using pairwise comparative judging and `eval.yaml` scenario definitions.

Tokens
358K
Snippets
722
Records
1.5K
Agent score
88%

What's inside dotnet-skills

  1. Overview of .NET Agent Skills

    main
    .NET Agent Skills is a curated collection of core skills and custom agents designed for coding agents. These plugins provide specialized capabilities for .NET development, including language server (LSP) integration, debugging, testing, and framework-specific expertise (like ASP.NET Core, Blazor, and MAUI).
  2. Overview of dotnet-test plugin

    main

    The dotnet-test plugin provides skills and agents for running, generating, analyzing, and improving tests. While originally built for .NET (MSTest, xUnit, NUnit, TUnit), many of its core features are polyglot and support multiple languages including Python, TypeScript/JavaScript, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell, and C++.

    Key Capabilities:

    • Test Execution: Run .NET tests with automatic detection.
    • Test Generation: Scaffold unit tests for any language via a multi-agent pipeline.
    • Test Quality Audit: Detect anti-patterns, smells, and assertion gaps (polyglot).
    • Coverage & Risk: Collect code coverage and compute CRAP scores (.NET only).
    • Testability Improvement: Identify and fix hard-to-test static dependencies (.NET only).

    Note: Test framework/platform migration (e.g., xUnit to MSTest) is handled by the separate dotnet-test-migration plugin.

  3. Understand BenchmarkDotNet (BDN) Core Concepts

    main

    When using BenchmarkDotNet (BDN) for microbenchmarking, understand these fundamental units of measurement:

    • Job: Defines the execution environment, including runtime, iteration counts, launch count, run strategy, and environment settings. Multiple jobs allow comparing the same code under different conditions.
    • Benchmark case: The atomic unit of measurement, defined as one method × one parameter combination × one job.
    • Operation: The logical unit of work. All BDN output (Mean, Error, etc.) is reported as time per operation.
    • Invocation: A single call to the benchmark method. By default, 1 invocation = 1 operation. If using OperationsPerInvoke=N, each invocation counts as N operations.
    • Iteration: A timed batch of invocations. BDN calculates per-operation time by dividing the total iteration time by the total operation count.
  4. Use the technology-selection skill for .NET AI/ML features

    main

    The technology-selection skill provides guidance for selecting and implementing AI and Machine Learning features in .NET 8+ applications. It covers a spectrum ranging from classic ML (classification, regression, clustering) to modern LLM orchestration (RAG pipelines, agentic workflows, tool calling) and local inference.

    Supported Technologies

    • ML.NET: Classic machine learning tasks.
    • Microsoft.Extensions.AI (MEAI): Standardized AI abstractions.
    • Microsoft Agent Framework (MAF): Agentic workflows.
    • GitHub Copilot SDK: Building Copilot extensions.
    • ONNX Runtime: Custom model inference.
    • OllamaSharp: Local LLM integration.

    Requirements and Constraints

    • Target Framework: Requires .NET 8+. This skill is not for .NET Framework projects.
    • Scope: Use this for AI/ML features. Do not use it for pure data engineering/ETL tasks without an ML component.
    • Deep Learning Training: If you need to train custom deep learning models from scratch, use Python (PyTorch/TensorFlow) and export to ONNX for .NET inference; this skill is for selection and implementation, not training loops.
  5. Use the dotnet-aot-compat skill for Native AOT and trimming compatibility

    main

    The dotnet-aot-compat skill is designed to help make .NET projects compatible with Native AOT and trimming by systematically resolving IL trim/AOT analyzer warnings.

    Use this skill for tasks such as:

    • Making projects AOT-compatible.
    • Fixing trimming or IL warnings (specifically IL2070, IL2067, IL2072, IL2026, and IL3050).
    • Adding [DynamicallyAccessedMembers] annotations.
    • Enabling IsAotCompatible in a .csproj file.
    • Annotating reflection code for the trimmer.

    Do NOT use this skill for:

    • Publishing native AOT binaries.
    • Optimizing binary size.
    • Replacing reflection-heavy libraries with alternatives.
    • Projects targeting .NET Framework (net4x), as they do not support trim/AOT analyzers.
  6. Understand the .NET Test Generation Pipeline

    main

    The .NET test generation pipeline is a multi-stage process designed to automate the creation of unit tests for C# projects. It consists of several specialized agents that move from research to implementation:

    1. code-testing-researcher: Analyzes the codebase to produce a research report (.testagent/research.md). It identifies the project structure, language version (.NET 9), test framework (e.g., MSTest), build/test commands, and prioritizes files for testing based on business logic density.
    2. code-testing-planner: Consumes the research output to create a structured implementation plan (.testagent/plan.md). This plan breaks down testing into phases, specifies which methods to cover (happy paths, edge cases, error scenarios), and defines success criteria.
    3. code-testing-implementer: Generates the actual test code (e.g., .cs files) based on the plan. It uses patterns like AAA (Arrange, Act, Assert) and mocking libraries (like Moq) to handle dependencies.
    4. code-testing-fixer: Automatically diagnoses and resolves build errors or test failures encountered during the implementation phase (e.g., missing NuGet packages or incorrect constructor arguments).
    5. code-testing-generator: Finalizes the process by producing a comprehensive Test Generation Report summarizing metrics, coverage, and build validation results.
  7. Use the test-gap-analysis skill for pseudo-mutation analysis

    main

    The test-gap-analysis skill performs static pseudo-mutation analysis on production code in any supported language to identify gaps in existing tests. Unlike standard code coverage, which only tracks if a line was executed, this skill reasons about hypothetical mutations (e.g., boolean flips, boundary changes, null returns) to determine if existing tests would actually fail if the code were broken.

    Use Cases

    • Evaluating if tests are strong enough to catch subtle bugs or logic changes.
    • Finding "blind spots" where tests pass even if the code is incorrect.
    • Identifying weak or shallow tests.
    • Prioritizing which tests need to be strengthened.
    • Serving as a self-review step for test-generation agents to verify the effectiveness of newly generated tests.

    Supported Languages

    Polyglot support includes: .NET, Python, TS/JS, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell, and C++.

    Inputs

    • Production code (Required): The source files to analyze for mutation points.
    • Test code (Required): The test files that cover the production code.
    • Focus area (Optional): A specific mutation category or code region to focus on.
  8. Discover language-specific guidance via Code Testing Extensions

    main
    The code-testing-extensions skill provides file paths to language-specific guidance files used in the code-testing pipeline. This skill is intended to be invoked by code-testing agents to discover which extension files are available for a target language. Once the file path is retrieved, the agent should read that file to obtain specific build commands, test commands, and framework-specific guidance.
  9. Use the coverage-analysis skill for .NET projects

    main

    The coverage-analysis skill provides project-wide code coverage and CRAP (Change Risk Anti-Patterns) score analysis. It identifies 'risk hotspots'—complex code with low coverage that is dangerous to modify. Use this to diagnose coverage plateaus, identify where to add tests, or determine if code is safe to refactor.

    Use this skill for:

    • Identifying where to add tests (ranked by risk/impact).
    • Distinguishing between risky uncovered code and trivial uncovered code using CRAP scores.
    • Finding files that are blocking coverage improvements.
    • Identifying complex, uncovered code that is dangerous to refactor.

    Do NOT use this skill for:

    • Targeted single-method CRAP analysis (use crap-score).
    • Writing or generating tests.
    • General test execution unrelated to coverage.
    • Simple coverage reporting without CRAP context (use dotnet test with coverage collection directly).
  10. Use the writing-mstest-tests skill

    main

    The writing-mstest-tests skill is designed to help you write, create, modernize, or fix comprehensive MSTest unit tests using MSTest 3.x/4.x APIs.

    Use this skill when you want to:

    • Write new MSTest unit tests from scratch.
    • Modernize existing MSTest tests (e.g., replacing Assert.IsTrue with specific assertions like Contains, IsInstanceOfType, or MatchesRegex).
    • Fix swapped Assert.AreEqual arguments (ensure Expected is first and Actual is second).
    • Replace ExpectedException with Assert.Throws.
    • Implement data-driven tests using DataRow, DynamicData, or ValueTuples.
    • Manage test lifecycles using TestInitialize, TestCleanup, or TestContext.
    • Implement async/cancellation patterns or conditional execution/retry logic.
    • Fix MSTest analyzer diagnostics (MSTESTxxxx).

    Do NOT use this skill for:

    • Test quality audits or anti-pattern detection (use test-anti-patterns).
    • Running or executing tests (use run-tests).
    • Migrating MSTest versions (use migrate-mstest-v1v2-to-v3 or migrate-mstest-v3-to-v4).
    • Testing with xUnit, NUnit, or TUnit.
  11. Understand the Shell Visual Hierarchy

    main

    MAUI Shell uses a four-level hierarchy for navigation. Each level wraps the one below it:

    1. Shell: The root container.
    2. FlyoutItem / TabBar: Top-level navigation grouping. FlyoutItem appears in the flyout menu; TabBar is a bottom tab bar used when no flyout is present.
    3. Tab: Groups ShellContent objects. Multiple ShellContent children within a single Tab create top tabs.
    4. ShellContent: Represents a specific ContentPage slot.

    Implicit Conversion

    You can simplify your XAML by omitting intermediate wrappers. Shell will automatically wrap elements as follows:

    • ShellContent only $\rightarrow$ FlyoutItem > Tab > ShellContent
    • Tab only $\rightarrow$ FlyoutItem > Tab
    • ShellContent inside a TabBar $\rightarrow$ TabBar > Tab > ShellContent