[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZP34TH7EFDPT0FP4Y7ZGA":3,"skill-same:01M6DZP34TH7EFDPT0FP4Y7ZGA":86},{"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":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M6DZP34TH7EFDPT0FP4Y7ZGA","scaffold-dotnet-test-project",null,"MUST USE when an existing .NET test project was excluded from a .slnf\u002FCI solution filter, disappeared from .sln\u002F.slnx discovery, or lost its production ProjectReference; also for requests to set up, create, reuse, add, register, include, or repair a test project. Handles \"tests pass directly but CI discovers zero\", exact solution wiring, xUnit\u002FNUnit\u002FMSTest, and central packages. DO NOT USE to only author tests in an already-wired project (code-testing), run tests, migrate, or correct MSTest syntax\u002Fconfiguration without changing project or CI files (writing-mstest-tests).","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",511,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test\u002Fskills\u002Fscaffold-dotnet-test-project\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","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,51,52],"test","dotnet","scaffold dotnet test project","scaffold","project","filter","only","up","files","do","repair","tests","register","correct","wiring","overlay","when","xunit","nunit","testing","migrate","discovery","SET","ZeRO","ci","code","create","packages","writing","2026-11-10 10:12:30",false,"---\nname: scaffold-dotnet-test-project\ndescription: >-\n  MUST USE when an existing .NET test project was excluded from a .slnf\u002FCI\n  solution filter, disappeared from .sln\u002F.slnx discovery, or lost its production\n  ProjectReference; also for requests to set up, create, reuse, add, register,\n  include, or repair a test project. Handles \"tests pass directly but CI\n  discovers zero\", exact solution wiring, xUnit\u002FNUnit\u002FMSTest, and central\n  packages. DO NOT USE to only author tests in an already-wired project\n  (code-testing), run tests, migrate, or correct MSTest syntax\u002Fconfiguration\n  without changing project or CI files (writing-mstest-tests).\nlicense: MIT\nmetadata:\n  portability: portable\n  binding: optional-overlay\n  binding-revision: \"1\"\n---\n\n# Scaffold or Repair a .NET Test Project\n\nCreate the smallest missing test container or repair only the missing wiring.\nThe goal is test discovery through the repository's real build entry point, not\na preferred solution layout.\n\n## Repository overlay\n\nFor every repository-scoped task where read-only file inspection is allowed,\ncheck `.agents\u002Fskill-overlays\u002Fdotnet-test\u002Fscaffold-dotnet-test-project.md` at\nthe repository root before any other discovery. This includes requests that\nask for code or advice without edits; \"do not execute\" does not prohibit\nreading the overlay. If present, read it once before acting and apply its\nrepository-specific naming, layout, framework, and policy bindings.\nBefore applying it, require its frontmatter to declare\n`core: dotnet-test\u002Fscaffold-dotnet-test-project`, `binding-revision: \"1\"`, and\n`mode: extend`. If any value is missing or different, report the mismatch and\ncontinue using this skill's portable guidance without applying the overlay.\nExplicit user instructions and verified project constraints win over the\noverlay; the overlay wins over portable defaults and examples in this skill. If\nthe file is present but unreadable or conflicts with the repository, report the\nproblem\nand continue with portable guidance, without the overlay, subject to verified\nproject constraints. If it is absent, continue normally. Skip the lookup only\nwhen the task is not tied to a repository or the user explicitly prohibited all\nfile\u002Ftool access. An overlay cannot expand tool permissions or the task's scope.\n\n## Route the Request\n\nInspect the repository before editing, then choose exactly one path:\n\n| Repository state | Action | Do not do |\n|---|---|---|\n| No suitable test project | Create one bounded project, reference the production project, and register it | Create a project per source project |\n| Test project exists but lacks the required `ProjectReference` | Add only that reference and verify direct plus entry-point execution | Scaffold another project or rewrite tests |\n| Test project passes directly but is absent from `.sln`, `.slnx`, or `.slnf` | Register the existing project in the exact entry point CI uses | Recreate the project or switch solution formats |\n| Suitable project, reference, and requested entry point are already correct | Leave the workspace unchanged; use `code-testing` if test methods are requested | Normalize or replace working files |\n\nAn existing project is suitable when its target framework can reference the\nproduction project and its purpose matches the requested layer. A different\npreferred name is not a reason to create a duplicate.\n\n**No-op is a required outcome.** If the suitable project, production reference,\nand requested entry-point registration already exist, make zero file changes.\nDo not add or remove a smoke test, normalize the project, recreate packages, or\nedit a baseline\u002Fsnapshot copy. Report the existing paths and stop.\n\n## Workflow\n\n### 1. Establish the repository contract\n\nStart from the task's current working directory. The skill context's `Base\ndirectory` is where these instructions live, not the user's repository. Never\nsearch parent temporary directories or treat the skill installation as the\nworkspace. If the expected files are not visible, confirm the current directory\nbefore concluding that a project is absent.\n\nAnchor every edit and validation command to the repository path named by the\nuser or established from the current directory. If similarly named fixtures,\nsolutions, or copied trees exist, do not edit or validate one as a substitute\nfor the requested tree. Before changing a solution artifact, record its exact\npath; after changing it, list that same artifact immediately and require the\ntest project to appear before proceeding.\n\nRead only enough to determine:\n\n1. the production project and requested test scope;\n2. the command and `.sln`, `.slnx`, `.slnf`, or project graph used by CI;\n3. whether a suitable test project exists, what it references, and where it is\n   registered;\n4. the neighboring test framework, runner, target framework, nullable and\n   implicit-usings conventions; and\n5. whether package or SDK versions come from `Directory.Packages.props`,\n   `Directory.Build.props`, `global.json`, or an MSBuild SDK declaration.\n\nIf the user reports that a test project passes directly but solution-level\ndiscovery finds nothing, treat that as registration evidence. Inspect the entry\npoint before considering project creation.\n\n### 2. Create only when the project is absent\n\nChoose one test project for the narrowest requested production project. Follow,\nin order, the user's explicit framework choice, neighboring test projects,\nrepository-wide package\u002FSDK conventions, then a standard SDK template.\n\nUse a `dotnet new` template only when its generated framework generation and\npackage style match the repository contract. Inspect template availability\nbefore creation. In particular, generic `dotnet new xunit` commonly emits xUnit\n2 packages; for a centrally managed `xunit.v3` repository, use a repository or\ninstalled xUnit v3 template, or create the minimal SDK project directly. Never\ngenerate versioned xUnit 2 references and then rewrite them into xUnit v3.\n\nThen:\n\n1. align target framework, nullable, implicit usings, runner, and package style;\n2. use `dotnet add \u003Ctest-project> reference \u003Cproduction-project>` for only the\n   production projects exercised by the requested tests;\n3. delete template sample files such as `UnitTest1.cs`, then create a\n   behavior-named test file rather than repurposing the template filename; and\n4. omit package versions when central package management supplies them.\n\nFor xUnit v3 projects using MTP, preserve or add the executable output and runner\nselection (or the equivalent supplied by the resolved package):\n\n```xml\n\u003COutputType>Exe\u003C\u002FOutputType>\n\u003CUseMicrosoftTestingPlatformRunner>true\u003C\u002FUseMicrosoftTestingPlatformRunner>\n```\n\nAdd `TestingPlatformDotnetTestSupport=true` only for the VSTest-command-mode\nbridge to MTP. It is not required for SDK 10+ native MTP mode selected by\n`global.json` `test.runner: Microsoft.Testing.Platform`. Use\n`platform-detection` to distinguish command mode from the executed runner;\nneither SDK version nor `OutputType=Exe` alone proves harness discovery.\n\n### 3. Repair only the missing edge when the project exists\n\n- Missing production reference: use `dotnet add \u003Ctest-project> reference\n  \u003Cproduction-project>`, inspect the resulting project, and leave every other\n  project element plus all test source files unchanged. Compare the project\n  before and after so the added `ProjectReference` is the only semantic change.\n- Missing `.sln` or `.slnx` registration: run `dotnet sln \u003Centry-point> add\n  \u003Ctest-project>`, then immediately run `dotnet sln \u003Centry-point> list` against\n  that exact path. If the project is absent, the repair has not happened; do not\n  validate a sibling solution or report success.\n- Missing `.slnf` registration: add the existing project to its underlying\n  solution if necessary, then include that same project path in the filter. If\n  the underlying solution already contains it, edit only the filter.\n- Multiple solution artifacts: modify only the one named by the user or invoked\n  by CI. Do not substitute an easier format.\n- No solution artifact: preserve the existing project-oriented workflow. Do not\n  create a solution for aesthetics.\n\n### 4. Add only the requested smoke behavior\n\nFor a newly created project, replace template examples with the smallest smoke\nsuite the user requested. Each test must invoke a real production symbol and\nassert a concrete deterministic result without network, wall-clock, process, or\nreal-filesystem dependencies.\n\nFor an existing-project wiring repair, do not add, rewrite, rename, or expand\ntests unless the user explicitly asks for test behavior changes. Registration\nand test authoring are separate operations.\n\n### 5. Verify the repaired path\n\nRun the narrowest commands that prove the chosen route:\n\nChoose command forms from the actual repository mode: native MTP uses\n`dotnet test --project \u003Ctest-project>` and `dotnet test --solution \u003Centry-point>`;\nVSTest command mode uses positional project\u002Fsolution paths, including when it\nbridges to MTP. Apply this distinction to every direct-project and entry-point\ntest below. Preserve the exact CI command and its supported `.slnf` invocation;\ndo not substitute a solution or invent unsupported switches.\nFor classic non-SDK projects, use the repository's documented MSBuild and\nnative test-runner commands instead of any `dotnet test` example below.\nIf that toolchain is unavailable, report the blocker without migrating the\nproject or claiming successful discovery.\n\n| Route | Required evidence |\n|---|---|\n| Newly created project | Mode-aware direct-project test, the exact entry-point command CI uses, and registration listing. If the entry point is a `.slnf`\u002F`.slnx` containing tests, run the repository's test command on that artifact rather than proving only that it builds. |\n| Missing reference | Targeted project test plus the exact solution\u002Froot test command requested |\n| Missing `.sln`\u002F`.slnx` registration | Listing and `dotnet test` for that exact artifact; never use another solution as a fallback |\n| Missing `.slnf` entry | Inspect the filter entry and run the exact CI filter build command; do not prepend a deliberately failing alternate command |\n| Already correct\u002Fno-op | Structural inspection of the existing reference and registration. Unless execution was requested, do not run tests merely to prove a no-op because that creates `bin`\u002F`obj` and weakens byte-for-byte cleanliness evidence. |\n\nInspect the repository's command before adding switches. Do not prepend a\nspeculative `--no-restore` attempt or hide alternatives in `command-a ||\ncommand-b`; run the configured entry-point command whose clean exit is the\nevidence.\n\nFor every wiring repair, invoke the exact validation command directly and\npreserve its exit status. Reading generated files, a grader script, or a later\nbuild is not a substitute for observing that command complete successfully.\n\nBefore reporting completion, inspect the final changed-file set. Remove only\n`bin`\u002F`obj` or equivalent build artifacts created by this task when they were\nabsent beforehand and are not intentionally tracked; never remove pre-existing\nartifacts. Preserve the passing command's complete result so the handoff can\nstate the exact entry point and discovered test count.\n\nFor a no-op, inspect rather than rewrite and report the existing paths. A green\n`dotnet build` is not test-discovery evidence. If validation is blocked, report\nthe exact failing command and first actionable error; never describe an unrun or\nfailed command as successful.\n\n## Output\n\nKeep the handoff proportional to the change:\n\n| Requirement | Evidence |\n|---|---|\n| Project created, reused, or repaired | Test project path and chosen route |\n| Production reference | Referenced `.csproj`, or why no change was needed |\n| Build registration | Exact `.sln`\u002F`.slnx`\u002F`.slnf` entry or project workflow |\n| Test discovery | Passing harness-level command and discovered test |\n\n## Completion Checks\n\n- Existing projects were checked before creation.\n- Only the requested production scope is referenced and tested.\n- Framework, runner, target framework, and central package conventions remain\n  intact.\n- Template samples are removed from a newly created project.\n- Existing test code is untouched for a wiring-only repair.\n- The exact repository entry point discovers and runs the test project.\n","# Scaffold or Repair a .NET Test Project\n\nCreate the smallest missing test container or repair only the missing wiring.\nThe goal is test discovery through the repository's real build entry point, not\na preferred solution layout.\n\n## Repository overlay\n\nFor every repository-scoped task where read-only file inspection is allowed,\ncheck `.agents\u002Fskill-overlays\u002Fdotnet-test\u002Fscaffold-dotnet-test-project.md` at\nthe repository root before any other discovery. This includes requests that\nask for code or advice without edits; \"do not execute\" does not prohibit\nreading the overlay. If present, read it once before acting and apply its\nrepository-specific naming, layout, framework, and policy bindings.\nBefore applying it, require its frontmatter to declare\n`core: dotnet-test\u002Fscaffold-dotnet-test-project`, `binding-revision: \"1\"`, and\n`mode: extend`. If any value is missing or different, report the mismatch and\ncontinue using this skill's portable guidance without applying the overlay.\nExplicit user instructions and verified project constraints win over the\noverlay; the overlay wins over portable defaults and examples in this skill. If\nthe file is present but unreadable or conflicts with the repository, report the\nproblem\nand continue with portable guidance, without the overlay, subject to verified\nproject constraints. If it is absent, continue normally. Skip the lookup only\nwhen the task is not tied to a repository or the user explicitly prohibited all\nfile\u002Ftool access. An overlay cannot expand tool permissions or the task's scope.\n\n## Route the Request\n\nInspect the repository before editing, then choose exactly one path:\n\n| Repository state | Action | Do not do |\n|---|---|---|\n| No suitable test project | Create one bounded project, reference the production project, and register it | Create a project per source project |\n| Test project exists but lacks the required `ProjectReference` | Add only that reference and verify direct plus entry-point execution | Scaffold another project or rewrite tests |\n| Test project passes directly but is absent from `.sln`, `.slnx`, or `.slnf` | Register the existing project in the exact entry point CI uses | Recreate the project or switch solution formats |\n| Suitable project, reference, and requested entry point are already correct | Leave the workspace unchanged; use `code-testing` if test methods are requested | Normalize or replace working files |\n\nAn existing project is suitable when its target framework can reference the\nproduction project and its purpose matches the requested layer. A different\npreferred name is not a reason to create a duplicate.\n\n**No-op is a required outcome.** If the suitable project, production reference,\nand requested entry-point registration already exist, make zero file changes.\nDo not add or remove a smoke test, normalize the project, recreate packages, or\nedit a baseline\u002Fsnapshot copy. Report the existing paths and stop.\n\n## Workflow\n\n### 1. Establish the repository contract\n\nStart from the task's current working directory. The skill context's `Base\ndirectory` is where these instructions live, not the user's repository. Never\nsearch parent temporary directories or treat the skill installation as the\nworkspace. If the expected files are not visible, confirm the current directory\nbefore concluding that a project is absent.\n\nAnchor every edit and validation command to the repository path named by the\nuser or established from the current directory. If similarly named fixtures,\nsolutions, or copied trees exist, do not edit or validate one as a substitute\nfor the requested tree. Before changing a solution artifact, record its exact\npath; after changing it, list that same artifact immediately and require the\ntest project to appear before proceeding.\n\nRead only enough to determine:\n\n1. the production project and requested test scope;\n2. the command and `.sln`, `.slnx`, `.slnf`, or project graph used by CI;\n3. whether a suitable test project exists, what it references, and where it is\n   registered;\n4. the neighboring test framework, runner, target framework, nullable and\n   implicit-usings conventions; and\n5. whether package or SDK versions come from `Directory.Packages.props`,\n   `Directory.Build.props`, `global.json`, or an MSBuild SDK declaration.\n\nIf the user reports that a test project passes directly but solution-level\ndiscovery finds nothing, treat that as registration evidence. Inspect the entry\npoint before considering project creation.\n\n### 2. Create only when the project is absent\n\nChoose one test project for the narrowest requested production project. Follow,\nin order, the user's explicit framework choice, neighboring test projects,\nrepository-wide package\u002FSDK conventions, then a standard SDK template.\n\nUse a `dotnet new` template only when its generated framework generation and\npackage style match the repository contract. Inspect template availability\nbefore creation. In particular, generic `dotnet new xunit` commonly emits xUnit\n2 packages; for a centrally managed `xunit.v3` repository, use a repository or\ninstalled xUnit v3 template, or create the minimal SDK project directly. Never\ngenerate versioned xUnit 2 references and then rewrite them into xUnit v3.\n\nThen:\n\n1. align target framework, nullable, implicit usings, runner, and package style;\n2. use `dotnet add \u003Ctest-project> reference \u003Cproduction-project>` for only the\n   production projects exercised by the requested tests;\n3. delete template sample files such as `UnitTest1.cs`, then create a\n   behavior-named test file rather than repurposing the template filename; and\n4. omit package versions when central package management supplies them.\n\nFor xUnit v3 projects using MTP, preserve or add the executable output and runner\nselection (or the equivalent supplied by the resolved package):\n\n```xml\n\u003COutputType>Exe\u003C\u002FOutputType>\n\u003CUseMicrosoftTestingPlatformRunner>true\u003C\u002FUseMicrosoftTestingPlatformRunner>\n```\n\nAdd `TestingPlatformDotnetTestSupport=true` only for the VSTest-command-mode\nbridge to MTP. It is not required for SDK 10+ native MTP mode selected by\n`global.json` `test.runner: Microsoft.Testing.Platform`. Use\n`platform-detection` to distinguish command mode from the executed runner;\nneither SDK version nor `OutputType=Exe` alone proves harness discovery.\n\n### 3. Repair only the missing edge when the project exists\n\n- Missing production reference: use `dotnet add \u003Ctest-project> reference\n  \u003Cproduction-project>`, inspect the resulting project, and leave every other\n  project element plus all test source files unchanged. Compare the project\n  before and after so the added `ProjectReference` is the only semantic change.\n- Missing `.sln` or `.slnx` registration: run `dotnet sln \u003Centry-point> add\n  \u003Ctest-project>`, then immediately run `dotnet sln \u003Centry-point> list` against\n  that exact path. If the project is absent, the repair has not happened; do not\n  validate a sibling solution or report success.\n- Missing `.slnf` registration: add the existing project to its underlying\n  solution if necessary, then include that same project path in the filter. If\n  the underlying solution already contains it, edit only the filter.\n- Multiple solution artifacts: modify only the one named by the user or invoked\n  by CI. Do not substitute an easier format.\n- No solution artifact: preserve the existing project-oriented workflow. Do not\n  create a solution for aesthetics.\n\n### 4. Add only the requested smoke behavior\n\nFor a newly created project, replace template examples with the smallest smoke\nsuite the user requested. Each test must invoke a real production symbol and\nassert a concrete deterministic result without network, wall-clock, process, or\nreal-filesystem dependencies.\n\nFor an existing-project wiring repair, do not add, rewrite, rename, or expand\ntests unless the user explicitly asks for test behavior changes. Registration\nand test authoring are separate operations.\n\n### 5. Verify the repaired path\n\nRun the narrowest commands that prove the chosen route:\n\nChoose command forms from the actual repository mode: native MTP uses\n`dotnet test --project \u003Ctest-project>` and `dotnet test --solution \u003Centry-point>`;\nVSTest command mode uses positional project\u002Fsolution paths, including when it\nbridges to MTP. Apply this distinction to every direct-project and entry-point\ntest below. Preserve the exact CI command and its supported `.slnf` invocation;\ndo not substitute a solution or invent unsupported switches.\nFor classic non-SDK projects, use the repository's documented MSBuild and\nnative test-runner commands instead of any `dotnet test` example below.\nIf that toolchain is unavailable, report the blocker without migrating the\nproject or claiming successful discovery.\n\n| Route | Required evidence |\n|---|---|\n| Newly created project | Mode-aware direct-project test, the exact entry-point command CI uses, and registration listing. If the entry point is a `.slnf`\u002F`.slnx` containing tests, run the repository's test command on that artifact rather than proving only that it builds. |\n| Missing reference | Targeted project test plus the exact solution\u002Froot test command requested |\n| Missing `.sln`\u002F`.slnx` registration | Listing and `dotnet test` for that exact artifact; never use another solution as a fallback |\n| Missing `.slnf` entry | Inspect the filter entry and run the exact CI filter build command; do not prepend a deliberately failing alternate command |\n| Already correct\u002Fno-op | Structural inspection of the existing reference and registration. Unless execution was requested, do not run tests merely to prove a no-op because that creates `bin`\u002F`obj` and weakens byte-for-byte cleanliness evidence. |\n\nInspect the repository's command before adding switches. Do not prepend a\nspeculative `--no-restore` attempt or hide alternatives in `command-a ||\ncommand-b`; run the configured entry-point command whose clean exit is the\nevidence.\n\nFor every wiring repair, invoke the exact validation command directly and\npreserve its exit status. Reading generated files, a grader script, or a later\nbuild is not a substitute for observing that command complete successfully.\n\nBefore reporting completion, inspect the final changed-file set. Remove only\n`bin`\u002F`obj` or equivalent build artifacts created by this task when they were\nabsent beforehand and are not intentionally tracked; never remove pre-existing\nartifacts. Preserve the passing command's complete result so the handoff can\nstate the exact entry point and discovered test count.\n\nFor a no-op, inspect rather than rewrite and report the existing paths. A green\n`dotnet build` is not test-discovery evidence. If validation is blocked, report\nthe exact failing command and first actionable error; never describe an unrun or\nfailed command as successful.\n\n## Output\n\nKeep the handoff proportional to the change:\n\n| Requirement | Evidence |\n|---|---|\n| Project created, reused, or repaired | Test project path and chosen route |\n| Production reference | Referenced `.csproj`, or why no change was needed |\n| Build registration | Exact `.sln`\u002F`.slnx`\u002F`.slnf` entry or project workflow |\n| Test discovery | Passing harness-level command and discovered test |\n\n## Completion Checks\n\n- Existing projects were checked before creation.\n- Only the requested production scope is referenced and tested.\n- Framework, runner, target framework, and central package conventions remain\n  intact.\n- Template samples are removed from a newly created project.\n- Existing test code is untouched for a wiring-only repair.\n- The exact repository entry point discovers and runs the test project.\n",{"name":5,"license":15,"metadata":58,"description":7},{"binding":59,"portability":60,"binding-revision":61},"optional-overlay","portable","1","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","external-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test\u002Fskills\u002Fscaffold-dotnet-test-project",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-10 19:58:06",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add managedcode\u002Fdotnet-skills --skill scaffold-dotnet-test-project",{"tool":78,"command":79},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill scaffold-dotnet-test-project",{"tool":81,"command":82},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill scaffold-dotnet-test-project","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test\u002Fskills\u002Fscaffold-dotnet-test-project\u002FSKILL.md",true,[],[87,120,142,173,183,209],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":101,"publishedAt":53},"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",[93,96],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[102,103,104,105,49,106,107,108,109,110,111,112,113,114,115,32,116,117,118,119],"xtwitter scraper","browser automation","workflows","run","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","social","commands","modeling","webhook",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":132,"publishedAt":53},"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",[126,129],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":130,"categoryName":131,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000036","内容创作者",[122,52,133,104,134,105,108,135,136,137,113,138,114,32,33,139,140,28,117,141],"performance","tasks","data","parsing","parser","context","writer","options","high-performance",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":53},"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",[],[149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,40],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","syntax","guide","use","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":53},"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",[],[175,161,32,180,181,169,182],"semantic","razor","inspection",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":53},"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",[],[190,191,192,193,52,194,195,196,197,198,199,161,30,200,201,202,33,203,204,205,206,169,207,208,40],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":217,"publishedAt":53},"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",[215,216],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},[109,218,219,220,105,221,156,190,161,201,202,33,222,223,224,225,206,169,226],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]