[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699DFP916JS530YGB2VRFC4":3,"skill-same:01M699DFP916JS530YGB2VRFC4":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M699DFP916JS530YGB2VRFC4","csharp-expert",null,"Route C# and .NET requests to the exact installed specialist or smallest dotnet\u002Fskills marketplace plugin. USE FOR: \"which specialist should own this\" or \"how do I add the skill\" requests involving ASP.NET Core endpoints, Blazor, MAUI binding, Windows Forms specialist selection or installation, EF Core queries, test framework migration (NUnit, xUnit, MSTest), framework migration, runtime CPU\u002Fallocation evidence, file-based C#, editor\u002Fcompiler defects, a surviving MSBuild `.binlog`, or a plugin missing from `\u002Fskills`; also use for C# semantics when no narrower specialist exists, including \"do I need another specialist?\" questions. DO NOT USE FOR: requests that already name the exact installed specialist to invoke, or work unrelated to C# or .NET.","microsoft\u002Ftestfx","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699C71CJ91B5WZ3AXG3GG2M",1059,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcsharp-expert\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"expert","csharp","csharp expert","route","windows","framework","add","allocation","forms","CPU","how","ef core","unrelated","work","when","invoke","blazor","selection","which","dotnet","editor","test","2026-11-10 10:12:30",false,"---\nname: csharp-expert\ndescription: >-\n  Route C# and .NET requests to the exact installed specialist or smallest dotnet\u002Fskills\n  marketplace plugin. USE FOR: \"which specialist should own this\" or \"how do I add the skill\"\n  requests involving ASP.NET Core endpoints, Blazor, MAUI binding, Windows Forms specialist\n  selection or installation, EF Core queries, test framework migration (NUnit, xUnit, MSTest),\n  framework migration, runtime CPU\u002Fallocation evidence, file-based C#, editor\u002Fcompiler defects,\n  a surviving MSBuild `.binlog`, or a plugin missing from `\u002Fskills`; also use for C# semantics\n  when no narrower specialist exists, including \"do I need another specialist?\" questions. DO NOT USE FOR: requests that already name the exact\n  installed specialist to invoke, or work unrelated to C# or .NET.\nlicense: MIT\n---\n\n# C# Expert\n\n## Purpose\n\nAct as the front door for C# and .NET work. Determine what the user wants, identify the kind of\nsolution that owns the work, invoke the narrowest installed specialist, and give exact\n`dotnet\u002Fskills` marketplace installation steps when that specialist is missing. Keep direct C#\nlanguage guidance as the fallback, not the default.\n\n## Routing Contract\n\n1. Classify the requested outcome from the prompt.\n2. Inspect the smallest set of repository files needed to identify the solution type.\n3. Compare both signals with the descriptions of the skills currently available to the runtime.\n4. If the best skill is available and the user asked to perform the downstream work, invoke it with\n   the `skill` tool as the first external action; do not emit a routing explanation before the\n   invocation and do not merely recommend the skill. For selection or preparation-only requests,\n   name the installed specialist and stop without invoking it.\n5. If the best skill is missing, identify its plugin in\n   `references\u002Fdotnet-skills-marketplace.md`, then decide whether the current task can still be\n   completed safely with repository tools and general .NET knowledge.\n6. Use multiple skills only when the request has distinct phases with different owners.\n7. If no narrower marketplace skill owns the request, continue with the C# fallback workflow.\n\nRouting is not task completion. A missing specialist changes the confidence and preferred workflow;\nit does not automatically justify stopping. Continue in the same turn when the task can be completed\nand validated without the specialist. Stop for installation only when the missing capability is\nactually required to proceed safely or the user asked specifically to install or load it.\n\nUse these fast paths before general repository exploration:\n\n- **Marketplace selection only:** when the prompt already states the framework, lifecycle, host, and\n  required behavior, read only the bundled marketplace reference. Do not inspect the fixture,\n  repository, GitHub, or plugin source. Name the exact skill and plugin, explain the decisive mapping,\n  give host-correct acquisition steps, and stop.\n- **Only surviving diagnostic artifact:** inspect that artifact first with the narrowest available\n  query. For a supplied `.binlog`, do not glob, list, or search unrelated workspace files before\n  extracting its recorded error, property, target, and path evidence.\n\nChoose the operating mode from the user's requested outcome:\n\n| User asks for | Required behavior |\n|---|---|\n| Implement, fix, diagnose, migrate, or create | Invoke the installed specialist, or complete a safe local fallback. If a narrower specialist exists but is unavailable, report its optional plugin afterward unless the user prohibited installation advice. |\n| Identify, choose, install, prepare, or load the right marketplace capability | Inspect enough solution evidence to choose the owner, name it whether installed or missing, give acquisition steps only when needed, and stop without invoking the specialist, editing files, or generating the requested application artifact. |\n| Recover a plugin already installed but absent from `\u002Fskills` | Refresh discovery first; do not reinstall or update on the first response. |\n\nChoose one owner per phase. Do not expose internal routing ceremony or turn the answer into a menu.\n\n## Step 1: Classify the Prompt\n\nIdentify the primary action before inspecting implementation details.\n\n| Prompt intent | Prefer skills whose description owns |\n|---|---|\n| Create or scaffold | Project\u002Ftemplate creation for the detected solution type |\n| Add application behavior | The framework or component where the behavior lives |\n| Fix a compiler\u002Fruntime defect | The narrow language, framework, data, or interop owner |\n| Build or restore failure | MSBuild, SDK, workload, project-reference, or NuGet diagnosis |\n| Write, run, review, or migrate tests | The exact testing lifecycle or migration requested |\n| Upgrade or migrate | The source version, target version, and artifact being migrated |\n| Diagnose slowness, crash, hang, or memory growth | Runtime diagnostics unless evidence points to build performance or a local code hot path |\n| Refactor without changing behavior | Refactoring rather than feature or bug-fix guidance |\n| Package, publish, or trust a feed | NuGet\u002Fpackage-publishing workflow |\n| Ask about C# syntax, types, nullability, async, or APIs | A language specialist unless solution-specific behavior is load-bearing |\n\nTreat user nouns as clues, not proof. \"Performance\" may mean runtime tracing, a microbenchmark, EF\nquery shape, SIMD, allocation-heavy C#, or MSBuild evaluation. \"API\" may mean ASP.NET Core, a public\nlibrary contract, or an external service client.\n\nWhen a deployed .NET process needs CPU and allocation evidence and no observability vendor is named,\nprefer the vendor-neutral .NET runtime diagnostics route. Do not substitute an APM-vendor agent for\nraw process evidence merely because it can also report performance data. In a selection answer,\nstate that runtime trace collection gathers deployed-process evidence before a hot method is known,\nwhereas source optimization starts from code or an already identified hot path.\n\n## Step 2: Detect the Solution Type\n\nInspect only likely manifests and nearby owning files. Prefer a solution\u002Fproject file and the file\nnamed by the prompt over broad repository searches.\n\nUse LSP navigation when available to trace a prompt-named symbol or file to its owning project and\nnearby callers. Use LSP diagnostics as early evidence, but do not treat them as a substitute for the\nspecialist's required build or runtime validation.\n\nWhen the prompt names a C# source file with an editor\u002Fcompiler defect and LSP is available, request\ndiagnostics before running a build or broad search. Use the diagnostic location and code to scope\nthe edit, request diagnostics again after the edit, then run the narrowest build or test that proves\nthe fix.\n\n| Evidence | Solution or concern |\n|---|---|\n| `Microsoft.NET.Sdk.Web`, controllers, endpoints, middleware, OpenAPI | ASP.NET Core |\n| `.razor`, `AddRazorComponents`, Blazor bootstrapping | Blazor |\n| `\u003CUseMaui>true\u003C\u002FUseMaui>`, `MauiProgram`, XAML pages | .NET MAUI |\n| `\u003CUseWindowsForms>true\u003C\u002FUseWindowsForms>`, `Form`, designer files | Windows Forms |\n| EF Core package references, `DbContext`, migrations | .NET data \u002F EF Core |\n| `\u003CIsTestProject>true\u003C\u002FIsTestProject>`, test SDK\u002Fframework packages | .NET testing |\n| `Directory.Build.*`, custom targets\u002Ftasks, `.binlog`, evaluation errors | MSBuild |\n| `Directory.Packages.props`, package restore\u002Fversion conflicts, feeds | NuGet |\n| Old and new TFMs, framework-version migration request, compatibility warnings | .NET upgrade |\n| `PublishAot`, trimming warnings, native library calls | AOT, interop, or deployment compatibility |\n| Aspire AppHost or distributed-application model | Aspire |\n| AI\u002FML\u002FLLM packages or agent\u002FRAG\u002FMCP application code | .NET AI |\n| No project plus an explicit request for a one-file C# program | File-based C# |\n| None of the above; correctness depends on C# semantics | C# language fallback |\n\nWhen several project types exist, trace from the file or behavior named in the prompt to its owning\nproject. Do not route the whole solution from the first `.csproj` found.\n\n## Step 3: Match the Skill and Marketplace Plugin\n\nUse the runtime-provided available-skill names and descriptions as the source of truth. Do not\nsearch for a skill installation directory or invoke a remembered skill that is not currently\navailable.\n\nRank candidates in this order:\n\n1. An exact transformation or lifecycle skill, such as a specific test migration, framework\n   conversion, template operation, query optimization, or diagnostic collection workflow.\n2. A framework\u002Fcomponent skill matching the owning project and requested behavior.\n3. A tooling skill matching the failing subsystem, such as MSBuild, NuGet, test execution, SDK\n   setup, or runtime diagnostics.\n4. A cross-cutting specialist matching the actual mechanism, such as interop, vectorization,\n   serialization, AOT, or microbenchmarking.\n5. `dotnet-breaking-changes` when the edit touches a contract with callers outside the repo: shipped\n   public API (`PublicAPI.*.txt`, ApiCompat), `InternalsVisibleTo` friends, multiple target\n   frameworks, or generated partials. Pair it with `csharp-refactoring` for a structural change.\n6. `csharp-refactoring` for behavior-preserving structural change.\n7. The C# language fallback below when no narrower available skill owns the work.\n\nBecause `csharp-expert` ships in the core `dotnet` plugin, prefer its installed sibling skills\n`csharp-refactoring`, `dotnet-breaking-changes`, `msbuild`, and `setup-local-sdk` when they own the\nrequest. Do not require the\nuser to install `dotnet-msbuild` merely to analyze an ordinary build failure or binlog that the\ncore `msbuild` entry already covers.\n\nThe most specific noun is not always the owner. Route by the decision that determines success:\n\n| Ambiguous request | Distinguishing evidence |\n|---|---|\n| \"Make this faster\" | Build duration -> build-performance skill; SQL\u002Fquery shape -> data skill; process CPU\u002Fmemory -> diagnostics; isolated code comparison -> microbenchmarking\u002Fvectorization |\n| \"Fix the API\" | HTTP pipeline\u002Fendpoint -> ASP.NET Core; public type contract -> C# fallback; JSON version behavior -> serialization specialist |\n| \"Upgrade the tests\" | Framework version change -> exact migration skill; failing execution -> run-tests\u002Fplatform skill; quality review -> analysis skill |\n| \"Fix nullability\" | Project-wide nullable adoption -> migration skill; one incorrect flow\u002Fcontract -> C# fallback; generated framework binding -> owning framework skill |\n| \"Add authentication\" | Framework-specific application auth -> owning framework skill; token parsing primitive -> C# fallback |\n\nIf two candidates remain plausible, gather one more decisive artifact rather than loading both.\n\nAfter selecting the capability:\n\n1. If its skill appears in the runtime's available-skill catalog, invoke it immediately only when\n   the operating mode requires downstream implementation. For selection or preparation-only mode,\n   name the installed skill and stop after the requested plan or availability guidance.\n2. If it does not appear, open `references\u002Fdotnet-skills-marketplace.md` and map the capability or\n   skill name to the owning marketplace plugin.\n3. Recommend the smallest plugin that contains the needed skill. Do not install every .NET plugin.\n4. Follow the missing-skill workflow below. Do not claim that an unavailable skill was loaded, and\n   do not stop if a safe, verifiable local fallback can still complete the request.\n\nWhen the bundled reference contains a maintained marketplace capability, recommend that capability.\nDo not ask the user to author a repository-local agent or skill as a substitute. For migrations,\nstate the source-to-target lifecycle and parameterization mappings that make the chosen capability\nfit, not only its name.\n\nFor marketplace-planning requests, name both the narrow skill and its plugin. Use project evidence\nto disambiguate framework nouns, but do not perform the downstream implementation the user asked to\nprepare for.\n\nFor migration selection, quote concrete source-to-target syntax from the bundled reference: include\nat least one lifecycle mapping and one parameterization mapping instead of saying only that those\nbehaviors are supported.\n\nUse the bundled marketplace reference as the authoritative lookup. Do not search GitHub, inspect\nunrelated plugin source, or enumerate alternatives after the prompt and one nearby manifest already\nidentify the owner. If the prompt already names the source and target lifecycle or an unambiguous\nartifact constraint, do not inspect files merely to reconfirm it. A selection request that states\nthe framework, lifecycle, and required behavior needs no repository search: read only the bundled\nreference, choose the owner, and answer. Do not inspect the local skill source, marketplace checkout,\nor fixture merely to prove that a named capability exists.\n\nAnswer in four compact parts:\n\n1. Exact skill name and plugin; never substitute a generic capability label when the bundled\n   reference contains an exact route.\n2. One sentence matching the decisive behavior or artifact evidence. Use the user's concrete\n   mechanism: N+1\u002Fdatabase round trips for repeated EF related-data queries; deployed-process\n   CPU\u002Fallocation collection before a known hot path for runtime tracing; source and target TFM\n   plus compatibility work for upgrades.\n3. Host-correct install steps.\n4. Restart\u002Fdiscovery verification, when the host requires it.\n\nFor a selection answer, completeness beats extra exploration. Read the bundled reference once,\nthen answer. Do not call host help, search the web, or inspect plugin source to reconfirm commands\nalready present in the reference.\n\nDo not add a `Route:` header in marketplace-planning mode; lead with the capability and plugin.\nDo not mention this skill's step numbers, fallback labels, routing contract, or internal selection\nprocess in the user-facing answer.\n\n## Step 4: Obtain a Missing Skill\n\nFor GitHub Copilot CLI or Claude Code, give these exact commands with the selected plugin substituted:\n\n```text\n\u002Fplugin marketplace add dotnet\u002Fskills\n\u002Fplugin install \u003Cplugin>@dotnet-agent-skills\n```\n\nWhen installation is the next step, require:\n\n```text\nRestart the host, run `\u002Fskills` to confirm the specialist is available, and rerun the request.\n```\n\nWhen the task can proceed without the specialist:\n\n1. State the missing specialist and reduced coverage in one concise sentence.\n2. Complete the requested work now using the repository, standard .NET tooling, and the fallback\n   rules that match the task.\n3. Validate the result as narrowly as possible.\n4. Put optional installation guidance after the result. Do not ask whether to proceed, defer the\n   implementation, or make the user repeat the request.\n\nIf the user explicitly says not to recommend or discuss installation, omit the missing-plugin\nsentence and all acquisition guidance. Complete and validate the safe fallback with the capabilities\navailable in the current run.\n\nThis reduced-coverage path may still perform framework, migration, diagnostics, or tooling work.\nPreserve the selected domain's invariants and report specialist-specific checks that were unavailable.\n\nRules:\n\n- The marketplace name is `dotnet-agent-skills`; the source repository is `dotnet\u002Fskills`.\n- The install target is the plugin name, not the individual skill name.\n- If the marketplace is already registered, the add command may report that fact; continue with the\n  install command.\n- Slash commands are host actions. Present them exactly; do not run shell commands that pretend to\n  install a Copilot or Claude plugin.\n- Do not pretend to continue with the unavailable specialist workflow. Use an explicit local\n  fallback when the task remains safely achievable.\n- If the plugin is installed but the skill is absent, ask the user to restart and check `\u002Fskills`\n  before recommending a reinstall.\n- For Codex CLI, VS Code, Cursor, or individual-skill installation, use the host-specific commands in\n  `references\u002Fdotnet-skills-marketplace.md`.\n- If installation is impossible, declined, or not necessary for the immediate task, state the\n  reduced coverage and use the safest local fallback when it can still satisfy the request.\n- Never trade away implementation or validation merely to produce installation instructions.\n\n### Installed but not discovered\n\nWhen the user says the plugin is already installed but its skills are absent:\n\n1. Trust the stated installed state unless repository evidence directly contradicts it.\n2. Start by acknowledging that the plugin is installed and discovery is stale.\n3. Tell the user to restart or reload the host, then run `\u002Fskills`.\n4. Name the expected skill so discovery can be verified.\n5. Stop there on the first response. Do not emit marketplace-add, install, update, shell-level\n   plugin-management, `\u002Fskills reload`, or invented explicit-invocation commands.\n\nOnly after the user reports that restart plus `\u002Fskills` still fails should the next response move to\nhost-specific update or reinstall diagnostics.\n\n## Step 5: Compose Skills Deliberately\n\nUse a sequence only when phases are independently owned. Examples:\n\n- Scaffold a project, then author a framework-specific component.\n- Collect a trace, then analyze the captured performance evidence.\n- Upgrade a target framework, then address a separately requested AOT compatibility phase.\n- Detect the test platform, then run tests with the correct filter syntax.\n\nDo not chain skills that duplicate each other, load an entire plugin \"just in case\", or use a\ngeneric skill before a specialist that already owns the request. After a specialist is loaded,\nfollow its workflow and boundaries.\n\nIf one or more phase specialists are missing but ordinary `dotnet` commands and repository edits\ncan complete the phases, execute the phases in order and report the optional plugins afterward.\nDo not defer an entire multi-phase request solely because the ideal plugin set is unavailable.\n\n## Step 6: C# Language Fallback\n\nUse this only when no narrower available skill matches and the load-bearing problem is C# language\nor runtime semantics.\n\n1. Reproduce the exact compiler diagnostic, failing test, exception, or incorrect behavior when\n   source is available. If the defect is fully specified but no repository was provided, answer\n   with the concrete minimal code pattern instead of refusing to help.\n2. Inspect the owning project for TFM, language version, nullable policy, analyzers, and existing\n   tests.\n3. Preserve public signatures, serialization shape, ownership, cancellation, disposal, and\n   multi-target behavior unless the request explicitly changes them.\n4. Implement the smallest complete fix through the affected call path.\n5. Check LSP diagnostics when available, then build the narrowest affected project and run focused\n   tests or the executable path that proves the original symptom is gone.\n\nFor a marketplace-planning request whose correct route is this fallback, say: `No additional\nmarketplace plugin is required; the loaded csharp-expert skill owns this C# semantic fix.` Do not\nclaim that no skill or specialist is involved.\n\nDo not raise the SDK, TFM, language version, package versions, or analyzer settings merely to make a\nlocal C# edit compile. Do not edit generated files. Do not use broad casts, null-forgiving\noperators, catch-all handlers, or fire-and-forget work to hide evidence.\n\nWhen a framework type provides an ownership-preserving overload such as `leaveOpen: true`, give that\ncanonical fix only. Never suggest intentionally leaking or skipping disposal of a disposable\nwrapper as an alternative. Preserve the example's observable behavior: do not add null coalescing,\nchange a nullable return to a non-null value, alter access modifiers, or invent unrelated error\nhandling merely to make a conceptual snippet look more complete. If an example directly returns\n`StreamReader.ReadLine()`, use a nullable `string?` return in nullable-aware C#; do not show\n`string` while claiming that the existing null-on-end-of-stream behavior is preserved.\n\n## Boundaries and Failure Handling\n\n- If the best specialist is unavailable, provide its exact `dotnet\u002Fskills` plugin installation\n  command. Continue immediately with an explicit reduced-coverage fallback whenever standard tools\n  can still complete and validate the task.\n- If repository evidence contradicts the prompt, state the mismatch and route from the evidence\n  that owns the requested file or behavior.\n- If the user explicitly requests analysis only, route to the correct analysis skill but do not\n  edit.\n- If the user supplies the only surviving diagnostic artifact, analyze that artifact directly.\n  Routing must not add installation attempts, unrelated checkout searches, or marketplace ceremony\n  before the evidence is read.\n- For an artifact-backed failure, propose only the smallest repair supported by the recorded\n  evidence. Do not add alternate configuration or relocation advice unless the artifact indicates\n  that the configured path is wrong rather than the required input being absent.\n- Describe a missing artifact at its exact configured relative path. Do not call a nested path such\n  as `schemas\u002Fprod.json` the repository root, and explicitly rule out build or CI configuration\n  changes when the recorded command already proves the configured path.\n- If a loaded specialist reports that its prerequisites are absent, return here, reclassify using\n  that evidence, and choose one different route. Do not bounce repeatedly between skills.\n- Non-.NET work is out of scope; leave this skill dormant rather than forcing a .NET interpretation.\n\n## Observable Completion Criteria\n\n- One evidence-backed owner is selected for each distinct phase and invoked when available.\n- Missing specialists map to the smallest correct plugin and host-specific acquisition path.\n- Safe local work continues despite a missing specialist; preparation-only requests stop before edits.\n- Pure C# work stays local and preserves behavior; implementation work receives focused validation.\n","# C# Expert\n\n## Purpose\n\nAct as the front door for C# and .NET work. Determine what the user wants, identify the kind of\nsolution that owns the work, invoke the narrowest installed specialist, and give exact\n`dotnet\u002Fskills` marketplace installation steps when that specialist is missing. Keep direct C#\nlanguage guidance as the fallback, not the default.\n\n## Routing Contract\n\n1. Classify the requested outcome from the prompt.\n2. Inspect the smallest set of repository files needed to identify the solution type.\n3. Compare both signals with the descriptions of the skills currently available to the runtime.\n4. If the best skill is available and the user asked to perform the downstream work, invoke it with\n   the `skill` tool as the first external action; do not emit a routing explanation before the\n   invocation and do not merely recommend the skill. For selection or preparation-only requests,\n   name the installed specialist and stop without invoking it.\n5. If the best skill is missing, identify its plugin in\n   `references\u002Fdotnet-skills-marketplace.md`, then decide whether the current task can still be\n   completed safely with repository tools and general .NET knowledge.\n6. Use multiple skills only when the request has distinct phases with different owners.\n7. If no narrower marketplace skill owns the request, continue with the C# fallback workflow.\n\nRouting is not task completion. A missing specialist changes the confidence and preferred workflow;\nit does not automatically justify stopping. Continue in the same turn when the task can be completed\nand validated without the specialist. Stop for installation only when the missing capability is\nactually required to proceed safely or the user asked specifically to install or load it.\n\nUse these fast paths before general repository exploration:\n\n- **Marketplace selection only:** when the prompt already states the framework, lifecycle, host, and\n  required behavior, read only the bundled marketplace reference. Do not inspect the fixture,\n  repository, GitHub, or plugin source. Name the exact skill and plugin, explain the decisive mapping,\n  give host-correct acquisition steps, and stop.\n- **Only surviving diagnostic artifact:** inspect that artifact first with the narrowest available\n  query. For a supplied `.binlog`, do not glob, list, or search unrelated workspace files before\n  extracting its recorded error, property, target, and path evidence.\n\nChoose the operating mode from the user's requested outcome:\n\n| User asks for | Required behavior |\n|---|---|\n| Implement, fix, diagnose, migrate, or create | Invoke the installed specialist, or complete a safe local fallback. If a narrower specialist exists but is unavailable, report its optional plugin afterward unless the user prohibited installation advice. |\n| Identify, choose, install, prepare, or load the right marketplace capability | Inspect enough solution evidence to choose the owner, name it whether installed or missing, give acquisition steps only when needed, and stop without invoking the specialist, editing files, or generating the requested application artifact. |\n| Recover a plugin already installed but absent from `\u002Fskills` | Refresh discovery first; do not reinstall or update on the first response. |\n\nChoose one owner per phase. Do not expose internal routing ceremony or turn the answer into a menu.\n\n## Step 1: Classify the Prompt\n\nIdentify the primary action before inspecting implementation details.\n\n| Prompt intent | Prefer skills whose description owns |\n|---|---|\n| Create or scaffold | Project\u002Ftemplate creation for the detected solution type |\n| Add application behavior | The framework or component where the behavior lives |\n| Fix a compiler\u002Fruntime defect | The narrow language, framework, data, or interop owner |\n| Build or restore failure | MSBuild, SDK, workload, project-reference, or NuGet diagnosis |\n| Write, run, review, or migrate tests | The exact testing lifecycle or migration requested |\n| Upgrade or migrate | The source version, target version, and artifact being migrated |\n| Diagnose slowness, crash, hang, or memory growth | Runtime diagnostics unless evidence points to build performance or a local code hot path |\n| Refactor without changing behavior | Refactoring rather than feature or bug-fix guidance |\n| Package, publish, or trust a feed | NuGet\u002Fpackage-publishing workflow |\n| Ask about C# syntax, types, nullability, async, or APIs | A language specialist unless solution-specific behavior is load-bearing |\n\nTreat user nouns as clues, not proof. \"Performance\" may mean runtime tracing, a microbenchmark, EF\nquery shape, SIMD, allocation-heavy C#, or MSBuild evaluation. \"API\" may mean ASP.NET Core, a public\nlibrary contract, or an external service client.\n\nWhen a deployed .NET process needs CPU and allocation evidence and no observability vendor is named,\nprefer the vendor-neutral .NET runtime diagnostics route. Do not substitute an APM-vendor agent for\nraw process evidence merely because it can also report performance data. In a selection answer,\nstate that runtime trace collection gathers deployed-process evidence before a hot method is known,\nwhereas source optimization starts from code or an already identified hot path.\n\n## Step 2: Detect the Solution Type\n\nInspect only likely manifests and nearby owning files. Prefer a solution\u002Fproject file and the file\nnamed by the prompt over broad repository searches.\n\nUse LSP navigation when available to trace a prompt-named symbol or file to its owning project and\nnearby callers. Use LSP diagnostics as early evidence, but do not treat them as a substitute for the\nspecialist's required build or runtime validation.\n\nWhen the prompt names a C# source file with an editor\u002Fcompiler defect and LSP is available, request\ndiagnostics before running a build or broad search. Use the diagnostic location and code to scope\nthe edit, request diagnostics again after the edit, then run the narrowest build or test that proves\nthe fix.\n\n| Evidence | Solution or concern |\n|---|---|\n| `Microsoft.NET.Sdk.Web`, controllers, endpoints, middleware, OpenAPI | ASP.NET Core |\n| `.razor`, `AddRazorComponents`, Blazor bootstrapping | Blazor |\n| `\u003CUseMaui>true\u003C\u002FUseMaui>`, `MauiProgram`, XAML pages | .NET MAUI |\n| `\u003CUseWindowsForms>true\u003C\u002FUseWindowsForms>`, `Form`, designer files | Windows Forms |\n| EF Core package references, `DbContext`, migrations | .NET data \u002F EF Core |\n| `\u003CIsTestProject>true\u003C\u002FIsTestProject>`, test SDK\u002Fframework packages | .NET testing |\n| `Directory.Build.*`, custom targets\u002Ftasks, `.binlog`, evaluation errors | MSBuild |\n| `Directory.Packages.props`, package restore\u002Fversion conflicts, feeds | NuGet |\n| Old and new TFMs, framework-version migration request, compatibility warnings | .NET upgrade |\n| `PublishAot`, trimming warnings, native library calls | AOT, interop, or deployment compatibility |\n| Aspire AppHost or distributed-application model | Aspire |\n| AI\u002FML\u002FLLM packages or agent\u002FRAG\u002FMCP application code | .NET AI |\n| No project plus an explicit request for a one-file C# program | File-based C# |\n| None of the above; correctness depends on C# semantics | C# language fallback |\n\nWhen several project types exist, trace from the file or behavior named in the prompt to its owning\nproject. Do not route the whole solution from the first `.csproj` found.\n\n## Step 3: Match the Skill and Marketplace Plugin\n\nUse the runtime-provided available-skill names and descriptions as the source of truth. Do not\nsearch for a skill installation directory or invoke a remembered skill that is not currently\navailable.\n\nRank candidates in this order:\n\n1. An exact transformation or lifecycle skill, such as a specific test migration, framework\n   conversion, template operation, query optimization, or diagnostic collection workflow.\n2. A framework\u002Fcomponent skill matching the owning project and requested behavior.\n3. A tooling skill matching the failing subsystem, such as MSBuild, NuGet, test execution, SDK\n   setup, or runtime diagnostics.\n4. A cross-cutting specialist matching the actual mechanism, such as interop, vectorization,\n   serialization, AOT, or microbenchmarking.\n5. `dotnet-breaking-changes` when the edit touches a contract with callers outside the repo: shipped\n   public API (`PublicAPI.*.txt`, ApiCompat), `InternalsVisibleTo` friends, multiple target\n   frameworks, or generated partials. Pair it with `csharp-refactoring` for a structural change.\n6. `csharp-refactoring` for behavior-preserving structural change.\n7. The C# language fallback below when no narrower available skill owns the work.\n\nBecause `csharp-expert` ships in the core `dotnet` plugin, prefer its installed sibling skills\n`csharp-refactoring`, `dotnet-breaking-changes`, `msbuild`, and `setup-local-sdk` when they own the\nrequest. Do not require the\nuser to install `dotnet-msbuild` merely to analyze an ordinary build failure or binlog that the\ncore `msbuild` entry already covers.\n\nThe most specific noun is not always the owner. Route by the decision that determines success:\n\n| Ambiguous request | Distinguishing evidence |\n|---|---|\n| \"Make this faster\" | Build duration -> build-performance skill; SQL\u002Fquery shape -> data skill; process CPU\u002Fmemory -> diagnostics; isolated code comparison -> microbenchmarking\u002Fvectorization |\n| \"Fix the API\" | HTTP pipeline\u002Fendpoint -> ASP.NET Core; public type contract -> C# fallback; JSON version behavior -> serialization specialist |\n| \"Upgrade the tests\" | Framework version change -> exact migration skill; failing execution -> run-tests\u002Fplatform skill; quality review -> analysis skill |\n| \"Fix nullability\" | Project-wide nullable adoption -> migration skill; one incorrect flow\u002Fcontract -> C# fallback; generated framework binding -> owning framework skill |\n| \"Add authentication\" | Framework-specific application auth -> owning framework skill; token parsing primitive -> C# fallback |\n\nIf two candidates remain plausible, gather one more decisive artifact rather than loading both.\n\nAfter selecting the capability:\n\n1. If its skill appears in the runtime's available-skill catalog, invoke it immediately only when\n   the operating mode requires downstream implementation. For selection or preparation-only mode,\n   name the installed skill and stop after the requested plan or availability guidance.\n2. If it does not appear, open `references\u002Fdotnet-skills-marketplace.md` and map the capability or\n   skill name to the owning marketplace plugin.\n3. Recommend the smallest plugin that contains the needed skill. Do not install every .NET plugin.\n4. Follow the missing-skill workflow below. Do not claim that an unavailable skill was loaded, and\n   do not stop if a safe, verifiable local fallback can still complete the request.\n\nWhen the bundled reference contains a maintained marketplace capability, recommend that capability.\nDo not ask the user to author a repository-local agent or skill as a substitute. For migrations,\nstate the source-to-target lifecycle and parameterization mappings that make the chosen capability\nfit, not only its name.\n\nFor marketplace-planning requests, name both the narrow skill and its plugin. Use project evidence\nto disambiguate framework nouns, but do not perform the downstream implementation the user asked to\nprepare for.\n\nFor migration selection, quote concrete source-to-target syntax from the bundled reference: include\nat least one lifecycle mapping and one parameterization mapping instead of saying only that those\nbehaviors are supported.\n\nUse the bundled marketplace reference as the authoritative lookup. Do not search GitHub, inspect\nunrelated plugin source, or enumerate alternatives after the prompt and one nearby manifest already\nidentify the owner. If the prompt already names the source and target lifecycle or an unambiguous\nartifact constraint, do not inspect files merely to reconfirm it. A selection request that states\nthe framework, lifecycle, and required behavior needs no repository search: read only the bundled\nreference, choose the owner, and answer. Do not inspect the local skill source, marketplace checkout,\nor fixture merely to prove that a named capability exists.\n\nAnswer in four compact parts:\n\n1. Exact skill name and plugin; never substitute a generic capability label when the bundled\n   reference contains an exact route.\n2. One sentence matching the decisive behavior or artifact evidence. Use the user's concrete\n   mechanism: N+1\u002Fdatabase round trips for repeated EF related-data queries; deployed-process\n   CPU\u002Fallocation collection before a known hot path for runtime tracing; source and target TFM\n   plus compatibility work for upgrades.\n3. Host-correct install steps.\n4. Restart\u002Fdiscovery verification, when the host requires it.\n\nFor a selection answer, completeness beats extra exploration. Read the bundled reference once,\nthen answer. Do not call host help, search the web, or inspect plugin source to reconfirm commands\nalready present in the reference.\n\nDo not add a `Route:` header in marketplace-planning mode; lead with the capability and plugin.\nDo not mention this skill's step numbers, fallback labels, routing contract, or internal selection\nprocess in the user-facing answer.\n\n## Step 4: Obtain a Missing Skill\n\nFor GitHub Copilot CLI or Claude Code, give these exact commands with the selected plugin substituted:\n\n```text\n\u002Fplugin marketplace add dotnet\u002Fskills\n\u002Fplugin install \u003Cplugin>@dotnet-agent-skills\n```\n\nWhen installation is the next step, require:\n\n```text\nRestart the host, run `\u002Fskills` to confirm the specialist is available, and rerun the request.\n```\n\nWhen the task can proceed without the specialist:\n\n1. State the missing specialist and reduced coverage in one concise sentence.\n2. Complete the requested work now using the repository, standard .NET tooling, and the fallback\n   rules that match the task.\n3. Validate the result as narrowly as possible.\n4. Put optional installation guidance after the result. Do not ask whether to proceed, defer the\n   implementation, or make the user repeat the request.\n\nIf the user explicitly says not to recommend or discuss installation, omit the missing-plugin\nsentence and all acquisition guidance. Complete and validate the safe fallback with the capabilities\navailable in the current run.\n\nThis reduced-coverage path may still perform framework, migration, diagnostics, or tooling work.\nPreserve the selected domain's invariants and report specialist-specific checks that were unavailable.\n\nRules:\n\n- The marketplace name is `dotnet-agent-skills`; the source repository is `dotnet\u002Fskills`.\n- The install target is the plugin name, not the individual skill name.\n- If the marketplace is already registered, the add command may report that fact; continue with the\n  install command.\n- Slash commands are host actions. Present them exactly; do not run shell commands that pretend to\n  install a Copilot or Claude plugin.\n- Do not pretend to continue with the unavailable specialist workflow. Use an explicit local\n  fallback when the task remains safely achievable.\n- If the plugin is installed but the skill is absent, ask the user to restart and check `\u002Fskills`\n  before recommending a reinstall.\n- For Codex CLI, VS Code, Cursor, or individual-skill installation, use the host-specific commands in\n  `references\u002Fdotnet-skills-marketplace.md`.\n- If installation is impossible, declined, or not necessary for the immediate task, state the\n  reduced coverage and use the safest local fallback when it can still satisfy the request.\n- Never trade away implementation or validation merely to produce installation instructions.\n\n### Installed but not discovered\n\nWhen the user says the plugin is already installed but its skills are absent:\n\n1. Trust the stated installed state unless repository evidence directly contradicts it.\n2. Start by acknowledging that the plugin is installed and discovery is stale.\n3. Tell the user to restart or reload the host, then run `\u002Fskills`.\n4. Name the expected skill so discovery can be verified.\n5. Stop there on the first response. Do not emit marketplace-add, install, update, shell-level\n   plugin-management, `\u002Fskills reload`, or invented explicit-invocation commands.\n\nOnly after the user reports that restart plus `\u002Fskills` still fails should the next response move to\nhost-specific update or reinstall diagnostics.\n\n## Step 5: Compose Skills Deliberately\n\nUse a sequence only when phases are independently owned. Examples:\n\n- Scaffold a project, then author a framework-specific component.\n- Collect a trace, then analyze the captured performance evidence.\n- Upgrade a target framework, then address a separately requested AOT compatibility phase.\n- Detect the test platform, then run tests with the correct filter syntax.\n\nDo not chain skills that duplicate each other, load an entire plugin \"just in case\", or use a\ngeneric skill before a specialist that already owns the request. After a specialist is loaded,\nfollow its workflow and boundaries.\n\nIf one or more phase specialists are missing but ordinary `dotnet` commands and repository edits\ncan complete the phases, execute the phases in order and report the optional plugins afterward.\nDo not defer an entire multi-phase request solely because the ideal plugin set is unavailable.\n\n## Step 6: C# Language Fallback\n\nUse this only when no narrower available skill matches and the load-bearing problem is C# language\nor runtime semantics.\n\n1. Reproduce the exact compiler diagnostic, failing test, exception, or incorrect behavior when\n   source is available. If the defect is fully specified but no repository was provided, answer\n   with the concrete minimal code pattern instead of refusing to help.\n2. Inspect the owning project for TFM, language version, nullable policy, analyzers, and existing\n   tests.\n3. Preserve public signatures, serialization shape, ownership, cancellation, disposal, and\n   multi-target behavior unless the request explicitly changes them.\n4. Implement the smallest complete fix through the affected call path.\n5. Check LSP diagnostics when available, then build the narrowest affected project and run focused\n   tests or the executable path that proves the original symptom is gone.\n\nFor a marketplace-planning request whose correct route is this fallback, say: `No additional\nmarketplace plugin is required; the loaded csharp-expert skill owns this C# semantic fix.` Do not\nclaim that no skill or specialist is involved.\n\nDo not raise the SDK, TFM, language version, package versions, or analyzer settings merely to make a\nlocal C# edit compile. Do not edit generated files. Do not use broad casts, null-forgiving\noperators, catch-all handlers, or fire-and-forget work to hide evidence.\n\nWhen a framework type provides an ownership-preserving overload such as `leaveOpen: true`, give that\ncanonical fix only. Never suggest intentionally leaking or skipping disposal of a disposable\nwrapper as an alternative. Preserve the example's observable behavior: do not add null coalescing,\nchange a nullable return to a non-null value, alter access modifiers, or invent unrelated error\nhandling merely to make a conceptual snippet look more complete. If an example directly returns\n`StreamReader.ReadLine()`, use a nullable `string?` return in nullable-aware C#; do not show\n`string` while claiming that the existing null-on-end-of-stream behavior is preserved.\n\n## Boundaries and Failure Handling\n\n- If the best specialist is unavailable, provide its exact `dotnet\u002Fskills` plugin installation\n  command. Continue immediately with an explicit reduced-coverage fallback whenever standard tools\n  can still complete and validate the task.\n- If repository evidence contradicts the prompt, state the mismatch and route from the evidence\n  that owns the requested file or behavior.\n- If the user explicitly requests analysis only, route to the correct analysis skill but do not\n  edit.\n- If the user supplies the only surviving diagnostic artifact, analyze that artifact directly.\n  Routing must not add installation attempts, unrelated checkout searches, or marketplace ceremony\n  before the evidence is read.\n- For an artifact-backed failure, propose only the smallest repair supported by the recorded\n  evidence. Do not add alternate configuration or relocation advice unless the artifact indicates\n  that the configured path is wrong rather than the required input being absent.\n- Describe a missing artifact at its exact configured relative path. Do not call a nested path such\n  as `schemas\u002Fprod.json` the repository root, and explicitly rule out build or CI configuration\n  changes when the recorded command already proves the configured path.\n- If a loaded specialist reports that its prerequisites are absent, return here, reclassify using\n  that evidence, and choose one different route. Do not bounce repeatedly between skills.\n- Non-.NET work is out of scope; leave this skill dormant rather than forcing a .NET interpretation.\n\n## Observable Completion Criteria\n\n- One evidence-backed owner is selected for each distinct phase and invoked when available.\n- Missing specialists map to the smallest correct plugin and host-specific acquisition path.\n- Safe local work continues despite a missing specialist; preparation-only requests stop before edits.\n- Pure C# work stays local and preserves behavior; implementation work receives focused validation.\n",{"name":5,"license":15,"description":7},"main","8bdfc29f415696738d845d56aca5d438d0a068de",".agents\u002Fskills\u002Fcsharp-expert",315,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 02:10:33",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add microsoft\u002Ftestfx --skill csharp-expert",{"tool":69,"command":70},"bunx","bunx skills add microsoft\u002Ftestfx --skill csharp-expert",{"tool":72,"command":73},"pnpm","pnpm dlx skills add microsoft\u002Ftestfx --skill csharp-expert","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcsharp-expert\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fdotnet-skills-marketplace.md","REFERENCE","参考文档",6242,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcsharp-expert\u002Freferences\u002Fdotnet-skills-marketplace.md",[84,109,134,155,175,199],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":49},"01M70GYY0AV0JGMTHE2CN6TNYK","dotnet-breaking-changes","Use before changing .NET\u002FC# code whose callers you do not control: a NuGet library, or a repo with PublicAPI.Shipped\u002FUnshipped.txt, ApiCompat, multiple TargetFrameworks, InternalsVisibleTo, or generated (.g.cs) partials. Green builds miss silent breaks from optional parameters, parameter names, sealing, const values, nullability, and #if. USE FOR: \"without breaking existing callers\"; adding a public method, overload, optional parameter, or interface member to a shipped library; renaming a public method or an internal helper a friend assembly uses; consolidating duplicated logic; changing a signature, nullability, default, or attribute; adding a target framework; RS0016\u002FRS0017 or ApiCompat errors; \"is this PR breaking?\". For a rename, extract, or merge, also invoke csharp-refactoring. DO NOT USE FOR: an executable whose callers all live in one project; renaming a local variable or private member, even in a shipped library; formatting; framework\u002FSDK\u002FNuGet upgrades (use dotnet-upgrade).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdotnet-breaking-changes\u002FSKILL.md",[],[46,91,92,93,94,95,96,97,98,99,100,42,101,102,103,104,105,106,107,108],"dotnet breaking changes","changes","green","project","default","local","errors","interface","generated","upgrade","you","code","refactoring","merge","rename","library","live","assembly",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":49},"01M699HHE9DTZWAMPB1ZR7ZKSW","testfx-test-value-evidence","Apply the vendored test-value-evidence skill with TestFx toolchain, assertion, parallel-safety, packed-consumer, and review conventions. Use when implementing or reviewing behavior-changing TestFx PRs or commits, including source-only changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-test-value-evidence\u002FSKILL.md",[115],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[48,117,118,119,120,121,122,123,124,125,126,127,128,41,129,130,92,131,132,133],"testfx test value evidence","test value evidence","evidence","value","review","parallel","toolchain","commits","implementing","prs","only","use","apply","with","behavior","Safety","conventions",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":49},"01M699HEYWH1B9XGNBFY8J2FZS","testfx-parallel-safety-preflight","Check concurrency and isolation before implementing or refactoring TestFx tests, lifecycle code, helpers, shared-state declarations, or production paths those tests exercise. Use before narrowing DoNotParallelize or ResourceLock, changing parallelization settings, or introducing asynchronous workers; repeat against the final diff.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-parallel-safety-preflight\u002FSKILL.md",[],[141,132,142,122,143,144,125,145,102,146,103,147,148,149,150,151,152,153,128,154],"testfx parallel safety preflight","preflight","shared","asynchronous","exercise","concurrency","paths","isolation","helpers","diff","parallelization","lifecycle","tests","workers",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":49},"01M699HC61ZV9GJ2C8JV03951G","testfx-localization-validation","Validate generated TestFx localization catalogs, resource IDs, placeholders and locked tokens. Use for RESX\u002FXLF changes, OneLoc PRs, localization build failures, duplicate targets or units, and orphaned translation entries.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-localization-validation\u002FSKILL.md",[],[162,163,164,165,166,167,168,169,170,126,99,128,171,172,92,173,174],"testfx localization validation","validation","localization","validate","translation","ids","for","tokens","entries","units","duplicate","targets","build",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":49},"01M699H9J2NWQXE4BDT6R0FH7S","testfx-acceptance-validation","Validate TestFx shipping paths and capable CI execution using packed consumers, package\u002Fcache provenance, exact exits and artifacts, and selected-versus-executed test evidence. Use for acceptance regressions, package\u002FMSBuild\u002Flauncher\u002Fprotocol changes, or skipped-only CI results; not for unrelated unit-only or documentation changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-acceptance-validation\u002FSKILL.md",[181],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[183,184,163,48,185,119,186,187,188,127,189,128,190,191,192,193,39,194,195,196,197,198,147,168],"testfx acceptance validation","acceptance","msbuild","launcher","ci","execution","package","cache","artifacts","provenance","documentation","shipping","results","protocol","unit","ci results",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":49},"01M699H70BB999BT4F627T1PHE","session-delivery-hygiene","Gate local-session scope, persistent delivery, live PR state, integration provenance, and owned cleanup. Use before implementing guidance changes, changing or pushing PR work, diagnosing package\u002Foutput mismatches, or handing off implementation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsession-delivery-hygiene\u002FSKILL.md",[],[206,207,208,209,210,125,96,211,40,107,212,189,128,192,213,214,92,215,216,217],"session delivery hygiene","delivery","session","hygiene","scope","cleanup","pr","output","state","integration","guidance","gate"]