[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZ1M0905C7X2ZF1F598GD9":3,"skill-same:01M6DZ1M0905C7X2ZF1F598GD9":95},{"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":23,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6DZ1M0905C7X2ZF1F598GD9","diagnostics-mcp",null,"Use dotnet-diagnostics-mcp for MCP-driven .NET CPU, allocation, GC, and test-host profiling. USE FOR: profiling unit tests or investigating runtime bottlenecks. DO NOT USE FOR: writing test assertions, coverage collection, or precise microbenchmark timing. INVOKES: connect the MCP server, select target processes, collect bounded profiles, and attribute hotspots to source.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",512,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FDotNet-Diagnostics-MCP\u002Fskills\u002Fdiagnostics-mcp\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"diagnostics mcp","diagnostics","MCP","access","advanced","unit","host","tests","runtime","artifact","do","gc","use","coverage","select","tool","collection","server","collect","permissions","capabilities","connect","unit tests","dotnet","support","mcp server","writing","2026-11-10 10:12:30",false,"---\nname: diagnostics-mcp\ndescription: \"Use dotnet-diagnostics-mcp for MCP-driven .NET CPU, allocation, GC, and test-host profiling. USE FOR: profiling unit tests or investigating runtime bottlenecks. DO NOT USE FOR: writing test assertions, coverage collection, or precise microbenchmark timing. INVOKES: connect the MCP server, select target processes, collect bounded profiles, and attribute hotspots to source.\"\ncompatibility: \"Global-tool installation requires the .NET SDK and a .NET 10 runtime; use an MCP client with stdio support, a writable physical artifact directory, and access to the target's diagnostic IPC endpoint. CoreCLR .NET 8\u002F9\u002F10 targets are supported; advanced collectors depend on OS capabilities and permissions.\"\n---\n\n# .NET Diagnostics MCP\n\n## Trigger On\n\n- The user asks to install or use `dotnet-diagnostics-mcp` for .NET performance investigation.\n- The user asks: **\"Profile all unit tests and identify bottlenecks in the code tested.\"**\n- An MCP-connected agent needs runtime evidence for CPU hotspots, allocation pressure, GC pauses, or waiting in a .NET application.\n\nUse this skill for this MCP server's workflow. Use the test framework's guidance for assertions and test authoring, and a benchmark workflow when the question needs precise per-operation timing.\n\n## Install and Connect\n\n```bash\ndotnet tool install -g dotnet-diagnostics-mcp\n# If already installed:\ndotnet tool update -g dotnet-diagnostics-mcp\ndotnet tool list -g\n```\n\nRegister `dotnet-diagnostics-mcp` with arguments `[\"--stdio\"]` in the client's native MCP settings, then reload its MCP connection. The client starts and owns the server subprocess; local stdio needs no HTTP daemon or bearer token. Ensure the client can resolve the global-tool command on `PATH`.\n\nFor example, Claude Desktop \u002F Cursor-style configuration:\n\n```json\n{\n  \"mcpServers\": {\n    \"dotnet-diagnostics\": {\n      \"command\": \"dotnet-diagnostics-mcp\",\n      \"args\": [\"--stdio\"]\n    }\n  }\n}\n```\n\nCheck `tools\u002Flist` for `inspect_process`, `collect_batch`, `collect_sample`, `collect_events`, and `query_snapshot`. Installing the tool alone does not connect it to the current AI session. If startup rejects symlink\u002Freparse-point paths, set the server's `MCP_ARTIFACT_ROOT` environment variable to an existing writable directory whose full path has no symlinks; see [tool patterns](references\u002Ftool-patterns.md).\n\n## Workflow\n\n1. Identify the requested workload, runtime, test runner, and unit-test projects. Build Release binaries with matching PDBs before the measured run. Keep build\u002Frestore time separate from test execution.\n2. For all-unit-test requests, follow [test profiling](references\u002Ftest-profiling.md): inventory projects, retain normal test parallelism, start the suite, and discover the actual test host or application process by command line. Record every relevant PID and its capture window.\n3. Resolve an explicit `processId` with `inspect_process(view=\"list\", commandLineContains=...)`. Use `view=\"info\"` to verify its identity. For a long-lived app, `view=\"triage\"` can choose the next collector; avoid spending a short test host's lifetime on preliminary captures.\n4. Capture CPU and managed allocations together with `collect_batch`; optionally add GC and counters, up to four entries. Use `depth=\"compact\"` and read the returned digest and per-entry errors before querying handles.\n5. Follow the hot path into the code under test. Separate product methods from runner, fixture, mocking, assertion, JIT, and profiler overhead. Use [tool patterns](references\u002Ftool-patterns.md) for collector selection and evidence limits.\n6. Reproduce a suspected hotspot with the runner's native test filter, preserving unrelated parallel execution. Compare equal workload, runtime, configuration, concurrency, and capture duration. Change code only within the user's requested scope, then rerun correctness checks and the same profile.\n\n```mermaid\nflowchart LR\n  A[\"Release build and unit-test inventory\"] --> B[\"Run tests with normal parallelism\"]\n  B --> C[\"inspect_process: actual test-host PIDs\"]\n  C --> D[\"collect_batch: CPU + allocation\"]\n  D --> E[\"query_snapshot: product hot paths\"]\n  E --> F[\"Focused reproduction and equal-workload comparison\"]\n  F --> G[\"Rank bottlenecks and disclose capture gaps\"]\n```\n\n## Practical MCP Calls\n\nThese are MCP tool arguments, not shell commands. Replace the illustrative PID and handle with values returned by the server.\n\nCollect a bounded profile of a running test host with `collect_batch`:\n\n```json\n{\n  \"processId\": 4242,\n  \"durationSeconds\": 10,\n  \"depth\": \"compact\",\n  \"requests\": [\n    { \"tool\": \"collect_sample\", \"kind\": \"cpu\" },\n    { \"tool\": \"collect_sample\", \"kind\": \"allocation\" }\n  ]\n}\n```\n\nRead the CPU or allocation handle's call tree with `query_snapshot`:\n\n```json\n{\n  \"handle\": \"\u003Creturned-handle>\",\n  \"view\": \"call-tree\",\n  \"topN\": 10,\n  \"maxDepth\": 8,\n  \"maxNodes\": 40,\n  \"depth\": \"compact\"\n}\n```\n\n## Deliver\n\n- Record tool\u002Fruntime versions, test command, configuration, normal concurrency, projects and test counts, PID identities, capture windows, and test exit status.\n- Rank bottlenecks by measured evidence: product method and source location when available, sample share or allocated-byte signal, affected test group, interpretation, and a concrete next change or measurement.\n- Report test-harness overhead separately. State missing hosts, missed execution intervals, failed collectors, unresolved symbols, and sampling limits. A passing suite and one captured PID do not prove every test was profiled.\n- Preserve useful bounded artifacts or exported traces and their paths. Handles expire and normally belong to the current MCP server session.\n\n## Validate\n\n- Confirm the MCP connection and advertised tool schemas; use current tool names and supported argument values.\n- Confirm samples came from the test host or app being tested, rather than the build process or SDK wrapper.\n- Check each batch entry for errors and verify the measured window overlaps real test execution. An empty profile is inconclusive.\n- Attribute EventPipe CPU results as stack-frequency evidence and allocation results as sampling evidence. Validate suspected waiting with counters, contention events, or a supported blocking collector.\n- Retain native test progress and ANSI. Show Warning\u002FError diagnostics plus one concise result; cap each diagnostic response at 80 lines \u002F 8 KiB, preserve the runner exit code, and keep necessary artifacts size-bounded outside model context.\n\nSource: [dotnet-diagnostics](https:\u002F\u002Fgithub.com\u002Fpedrosakuma\u002Fdotnet-diagnostics). Read [test profiling](references\u002Ftest-profiling.md) for suite coverage and [tool patterns](references\u002Ftool-patterns.md) for setup, drilldown, settings, and source links.\n","# .NET Diagnostics MCP\n\n## Trigger On\n\n- The user asks to install or use `dotnet-diagnostics-mcp` for .NET performance investigation.\n- The user asks: **\"Profile all unit tests and identify bottlenecks in the code tested.\"**\n- An MCP-connected agent needs runtime evidence for CPU hotspots, allocation pressure, GC pauses, or waiting in a .NET application.\n\nUse this skill for this MCP server's workflow. Use the test framework's guidance for assertions and test authoring, and a benchmark workflow when the question needs precise per-operation timing.\n\n## Install and Connect\n\n```bash\ndotnet tool install -g dotnet-diagnostics-mcp\n# If already installed:\ndotnet tool update -g dotnet-diagnostics-mcp\ndotnet tool list -g\n```\n\nRegister `dotnet-diagnostics-mcp` with arguments `[\"--stdio\"]` in the client's native MCP settings, then reload its MCP connection. The client starts and owns the server subprocess; local stdio needs no HTTP daemon or bearer token. Ensure the client can resolve the global-tool command on `PATH`.\n\nFor example, Claude Desktop \u002F Cursor-style configuration:\n\n```json\n{\n  \"mcpServers\": {\n    \"dotnet-diagnostics\": {\n      \"command\": \"dotnet-diagnostics-mcp\",\n      \"args\": [\"--stdio\"]\n    }\n  }\n}\n```\n\nCheck `tools\u002Flist` for `inspect_process`, `collect_batch`, `collect_sample`, `collect_events`, and `query_snapshot`. Installing the tool alone does not connect it to the current AI session. If startup rejects symlink\u002Freparse-point paths, set the server's `MCP_ARTIFACT_ROOT` environment variable to an existing writable directory whose full path has no symlinks; see [tool patterns](references\u002Ftool-patterns.md).\n\n## Workflow\n\n1. Identify the requested workload, runtime, test runner, and unit-test projects. Build Release binaries with matching PDBs before the measured run. Keep build\u002Frestore time separate from test execution.\n2. For all-unit-test requests, follow [test profiling](references\u002Ftest-profiling.md): inventory projects, retain normal test parallelism, start the suite, and discover the actual test host or application process by command line. Record every relevant PID and its capture window.\n3. Resolve an explicit `processId` with `inspect_process(view=\"list\", commandLineContains=...)`. Use `view=\"info\"` to verify its identity. For a long-lived app, `view=\"triage\"` can choose the next collector; avoid spending a short test host's lifetime on preliminary captures.\n4. Capture CPU and managed allocations together with `collect_batch`; optionally add GC and counters, up to four entries. Use `depth=\"compact\"` and read the returned digest and per-entry errors before querying handles.\n5. Follow the hot path into the code under test. Separate product methods from runner, fixture, mocking, assertion, JIT, and profiler overhead. Use [tool patterns](references\u002Ftool-patterns.md) for collector selection and evidence limits.\n6. Reproduce a suspected hotspot with the runner's native test filter, preserving unrelated parallel execution. Compare equal workload, runtime, configuration, concurrency, and capture duration. Change code only within the user's requested scope, then rerun correctness checks and the same profile.\n\n```mermaid\nflowchart LR\n  A[\"Release build and unit-test inventory\"] --> B[\"Run tests with normal parallelism\"]\n  B --> C[\"inspect_process: actual test-host PIDs\"]\n  C --> D[\"collect_batch: CPU + allocation\"]\n  D --> E[\"query_snapshot: product hot paths\"]\n  E --> F[\"Focused reproduction and equal-workload comparison\"]\n  F --> G[\"Rank bottlenecks and disclose capture gaps\"]\n```\n\n## Practical MCP Calls\n\nThese are MCP tool arguments, not shell commands. Replace the illustrative PID and handle with values returned by the server.\n\nCollect a bounded profile of a running test host with `collect_batch`:\n\n```json\n{\n  \"processId\": 4242,\n  \"durationSeconds\": 10,\n  \"depth\": \"compact\",\n  \"requests\": [\n    { \"tool\": \"collect_sample\", \"kind\": \"cpu\" },\n    { \"tool\": \"collect_sample\", \"kind\": \"allocation\" }\n  ]\n}\n```\n\nRead the CPU or allocation handle's call tree with `query_snapshot`:\n\n```json\n{\n  \"handle\": \"\u003Creturned-handle>\",\n  \"view\": \"call-tree\",\n  \"topN\": 10,\n  \"maxDepth\": 8,\n  \"maxNodes\": 40,\n  \"depth\": \"compact\"\n}\n```\n\n## Deliver\n\n- Record tool\u002Fruntime versions, test command, configuration, normal concurrency, projects and test counts, PID identities, capture windows, and test exit status.\n- Rank bottlenecks by measured evidence: product method and source location when available, sample share or allocated-byte signal, affected test group, interpretation, and a concrete next change or measurement.\n- Report test-harness overhead separately. State missing hosts, missed execution intervals, failed collectors, unresolved symbols, and sampling limits. A passing suite and one captured PID do not prove every test was profiled.\n- Preserve useful bounded artifacts or exported traces and their paths. Handles expire and normally belong to the current MCP server session.\n\n## Validate\n\n- Confirm the MCP connection and advertised tool schemas; use current tool names and supported argument values.\n- Confirm samples came from the test host or app being tested, rather than the build process or SDK wrapper.\n- Check each batch entry for errors and verify the measured window overlaps real test execution. An empty profile is inconclusive.\n- Attribute EventPipe CPU results as stack-frequency evidence and allocation results as sampling evidence. Validate suspected waiting with counters, contention events, or a supported blocking collector.\n- Retain native test progress and ANSI. Show Warning\u002FError diagnostics plus one concise result; cap each diagnostic response at 80 lines \u002F 8 KiB, preserve the runner exit code, and keep necessary artifacts size-bounded outside model context.\n\nSource: [dotnet-diagnostics](https:\u002F\u002Fgithub.com\u002Fpedrosakuma\u002Fdotnet-diagnostics). Read [test profiling](references\u002Ftest-profiling.md) for suite coverage and [tool patterns](references\u002Ftool-patterns.md) for setup, drilldown, settings, and source links.\n",{"name":5,"description":7,"compatibility":56},"Global-tool installation requires the .NET SDK and a .NET 10 runtime; use an MCP client with stdio support, a writable physical artifact directory, and access to the target's diagnostic IPC endpoint. CoreCLR .NET 8\u002F9\u002F10 targets are supported; advanced collectors depend on OS capabilities and permissions.","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","catalog\u002FTools\u002FDotNet-Diagnostics-MCP\u002Fskills\u002Fdiagnostics-mcp",41,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills","https:\u002F\u002Fskills.managed-code.com","https:\u002F\u002Fgithub.com\u002Fmanagedcode","https:\u002F\u002Fwww.managed-code.com","Open Source Community for .NET Developers: Reliable, Actively Maintained, and Community-Driven. Made in Ukraine 🇺🇦 with ❤️","2026-11-11 19:34:28",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add managedcode\u002Fdotnet-skills --skill diagnostics-mcp",{"tool":73,"command":74},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill diagnostics-mcp",{"tool":76,"command":77},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill diagnostics-mcp","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FDotNet-Diagnostics-MCP\u002Fskills\u002Fdiagnostics-mcp\u002FSKILL.md",true,[81,87,91],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"manifest.json","REFERENCE","参考文档",100,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FDotNet-Diagnostics-MCP\u002Fskills\u002Fdiagnostics-mcp\u002Fmanifest.json",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Ftest-profiling.md",5941,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FDotNet-Diagnostics-MCP\u002Fskills\u002Fdiagnostics-mcp\u002Freferences\u002Ftest-profiling.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Ftool-patterns.md",6662,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FDotNet-Diagnostics-MCP\u002Fskills\u002Fdiagnostics-mcp\u002Freferences\u002Ftool-patterns.md",[96,130,153,184,194,221],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":110,"publishedAt":51},"01M6DYQE1Y9FHAQHEDTVFQ3447","xtwitter-scraper","Use XTwitterScraper when a .NET application needs typed access to Xquik's X automation REST API for tweet search, user lookup, posting workflows, extraction jobs, monitors, webhooks, or giveaway draws. USE FOR: integrating the XTwitterScraper NuGet package; reviewing Xquik API client usage; modeling API-key configuration, pagination, binary exports, raw responses, retries, and webhook\u002Fevent flows in .NET. DO NOT USE FOR: unrelated stacks; direct browser automation; generic social-media strategy; or code that does not call Xquik. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FXTwitterScraper\u002Fskills\u002Fxtwitter-scraper\u002FSKILL.md",[102,105],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[111,112,113,114,115,116,117,118,119,120,121,27,122,123,124,125,126,127,128,129],"xtwitter scraper","browser automation","workflows","run","code","browser","search","repository","api","Media","api client","edit","unrelated","webhooks","files","social","commands","modeling","webhook",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":142,"publishedAt":51},"01M6DYQ9S4PE1H6G8MCH9T21HR","sep","Use Sep for high-performance separated-value parsing and writing in .NET, including delimiter inference, explicit parser\u002Fwriter options, and low-allocation row\u002Fcolumn workflows. USE FOR: delimited data needs are performance-sensitive and allocation-aware; project needs explicit control over separator inference, escaping, trimming, and header behavior;. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FSep\u002Fskills\u002Fsep\u002FSKILL.md",[136,139],{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":140,"categoryName":141,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000036","内容创作者",[132,50,143,113,144,114,118,145,146,147,122,148,123,125,34,149,150,151,127,152],"performance","tasks","data","parsing","parser","context","writer","options","project","high-performance",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":51},"01M6DZS2DNEPXCGGF6SSCW6G5V","webgpu-threejs-tsl","Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fwebgpu-claude-skill\u002Fskills\u002Fwebgpu-threejs-tsl\u002FSKILL.md",[],[160,161,162,163,164,165,166,167,168,169,170,171,36,172,173,174,175,176,177,178,179,180,181,182,183],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","syntax","guide","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects","when",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":51},"01M6DZS0BQXW2B56A289XF1X76","roslynk","Use Roslynk for semantic inspection and edits of *.cs, *.razor and *.cshtml solution files.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Froslynk\u002Fskills\u002Froslynk\u002FSKILL.md",[],[186,36,125,191,192,179,193],"semantic","razor","inspection",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":51},"01M6DZRW6MEJCVW80K3S4XV60K","system-text-json-net11","Imperative guidance for the System.Text.Json APIs added in .NET 11: the built-in `JsonNamingPolicy.PascalCase` naming policy, and the strongly-typed generic `JsonSerializerOptions.GetTypeInfo` and `JsonSerializerOptions.TryGetTypeInfo` metadata accessors (generic overloads that return a typed `JsonTypeInfo`). USE ONLY when the user is targeting net11.0 or later and needs PascalCase JSON property or dictionary-key names without writing a custom naming policy, a strongly-typed generic `JsonTypeInfo` instead of the non-generic `JsonTypeInfo`, or a no-throw way to probe whether a type's serialization metadata is resolved. DO NOT USE when the target is earlier than net11.0, the requested behavior uses an established pre-net11 naming policy, or the user explicitly selected another JSON library.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fsystem-text-json-net11\u002FSKILL.md",[],[201,202,203,204,50,205,206,207,208,209,210,36,211,212,213,214,34,215,216,217,218,179,219,220,183],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","only","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":229,"publishedAt":51},"01M6DZRRJP3S662NFSG1RSPQQ7","process-api-net11","Provides guidance on the new System.Diagnostics.Process APIs introduced in .NET 11: Process.Run, Process.RunAndCaptureText, Process.StartAndForget, Process.ReadAllText\u002FBytes\u002FLines, KillOnParentExit, InheritedHandles, and StartDetached. USE FOR: starting, orchestrating, or capturing output from external processes in applications targeting net11.0 or later. DO NOT USE FOR: applications targeting .NET 10 or earlier, or basic pre-.NET 11 Process.Start usage without new APIs.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fprocess-api-net11\u002FSKILL.md",[227,228],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},[119,230,231,25,114,232,167,201,36,213,214,34,233,234,235,236,218,179,237],"process","process api net11","start","basic","processes","output","usage","new"]