[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZRFJDY56KA3J1NQ3BC5SV":3,"skill-same:01M6DZRFJDY56KA3J1NQ3BC5SV":122},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6DZRFJDY56KA3J1NQ3BC5SV","msbuild",null,"Use before MSBuild custom-target or incremental-generation repairs, XML\u002Fimport\u002Fhook review, .binlog capture\u002Freplay, or assessing supported\u002Funsupported build-speedup claims and controlled timings, even without a checkout. For MSBuild authoring itself, activate before reviewing\u002Fediting .proj\u002F.props\u002F.targets\u002F.csproj\u002F.fsproj\u002F.vbproj or Directory.Build files, including no-change import reviews. Framework\u002FAPI\u002F.NET\u002FASP.NET upgrade plans and working non-SDK-to-SDK\u002Fpackages.config conversions are migrations, even if they mention .csproj\u002FNuGet: DO NOT activate. A failing assertion after a successful build is code\u002Ftest debugging: DO NOT activate. Check Import\u002FExists, required and NuGet build\u002FbuildTransitive\u002Fnuspec imports, conditions, Inputs\u002FOutputs, stale outputs and incorrect skips. Build checks use copies; source inputs stay read-only. Diagnose failed dotnet build\u002Frestore\u002Fpack\u002Fpublish or slow evaluation\u002Fcompilation\u002Fcopying. Exclude SDK installation alone, C# refactoring, runtime CPU profiling and non-MSBuild builds.","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\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"reviews","imports","claims","code","debugging","upgrade","files","failing","csproj","cpu profiling","change","packages","publish","review","api","activate","dotnet","only","checkout","2026-11-10 10:12:30",false,"---\nname: msbuild\ndescription: \"Use before MSBuild custom-target or incremental-generation repairs, XML\u002Fimport\u002Fhook review, .binlog capture\u002Freplay, or assessing supported\u002Funsupported build-speedup claims and controlled timings, even without a checkout. For MSBuild authoring itself, activate before reviewing\u002Fediting .proj\u002F.props\u002F.targets\u002F.csproj\u002F.fsproj\u002F.vbproj or Directory.Build files, including no-change import reviews. Framework\u002FAPI\u002F.NET\u002FASP.NET upgrade plans and working non-SDK-to-SDK\u002Fpackages.config conversions are migrations, even if they mention .csproj\u002FNuGet: DO NOT activate. A failing assertion after a successful build is code\u002Ftest debugging: DO NOT activate. Check Import\u002FExists, required and NuGet build\u002FbuildTransitive\u002Fnuspec imports, conditions, Inputs\u002FOutputs, stale outputs and incorrect skips. Build checks use copies; source inputs stay read-only. Diagnose failed dotnet build\u002Frestore\u002Fpack\u002Fpublish or slow evaluation\u002Fcompilation\u002Fcopying. Exclude SDK installation alone, C# refactoring, runtime CPU profiling and non-MSBuild builds.\"\nlicense: MIT\n---\n\n# MSBuild troubleshooting\n\nFor advice or static review, answer from the supplied XML, package facts, or measurements when\nthey settle the question: no reference reads, checkout discovery, commands, or invented verification.\nFor requested work, start at the supplied project or artifact; discover only what the next decision\nneeds. Read a reference only for a specific unresolved question. References are not invocable skills.\n\n## Start with the task and evidence\n\nBefore editing, follow repository instructions and inspect the project\u002Fimports. Preserve the original\ncommand, working directory, SDK, configuration, target framework, runtime identifier, global properties,\nand target. Ask only for consequential information that cannot be discovered.\n\nAn existing `.binlog` can be the only available artifact. Analyze it before requesting a new\nbuild; paths inside it do not prove a checkout exists locally.\n\nFor a mixed request, fix correctness before measuring successful builds, and keep authoring review\nseparate from a performance experiment. A failing test assertion after a successful build is not\nan MSBuild failure.\n\n**Capture only:** choose an unused artifact path under the supplied workspace, unless the user\nspecified another artifact directory. Do not put the only deliverable in a shared\u002Fglobal\ntemporary directory where workspace artifact collection will miss it, or stage\u002Fcommit the log.\nAppend the binary logger to the exact supplied command, run it once, and save its original\nexit code before checking the new log is nonempty.\nReport the artifact path and original exit code, then stop: no replay, diagnosis, or repair.\nRead [capture details](references\u002Fbinlog-generation.md) only for an unresolved wrapper,\nlogger-option, toolset, or privacy question.\n\n## 1. Troubleshoot build issues\n\n**Goal:** identify the independent root causes and make the smallest repair, not a broad cleanup.\n\n| Situation | Reference if needed | Action |\n| --- | --- | --- |\n| A build failed and a binary log exists | [binlog-failure-analysis](references\u002Fbinlog-failure-analysis.md) | Replay the log with MSBuild; connect errors to the responsible project instance, target, and task. Separate root causes from cascading failures. |\n| The failure needs evidence and no matching log exists | [binlog-generation](references\u002Fbinlog-generation.md), then [failure analysis](references\u002Fbinlog-failure-analysis.md) | Capture the original invocation once and verify the artifact. Analyze it only when requested. |\n| A project\u002Fbuild file has incorrect conditions, items, properties, or output paths | [msbuild-antipatterns](references\u002Fmsbuild-antipatterns.md) | Select the relevant catalog entries and check their exceptions before changing anything. |\n| Imports or build hooks are missing, overwritten, or run in the wrong order | [extension-points](references\u002Fextension-points.md) | Inspect the import contract, discovery order, and packed NuGet layout rather than hiding a required failure. |\n| Outputs are stale or required work is skipped | [incremental-build](references\u002Fincremental-build.md) | Track input-set membership as well as file timestamps; apply the repair contract below. |\n\nFor build-wiring-only work, generator and source inputs are **read-only throughout**, not restored\nafter tests; edit the original only as the requested repair requires.\nAllocate disposable scratch as a uniquely named directory **outside the project tree**, normally\nthe OS temporary directory from `mktemp -d`; a copy inside the project can be matched by SDK\ndefault globs and break the later confirming build. Print the path once and write every copy, log,\nand hash under it: no fixed leaf names, pointer files, pre-deleting, or globbing to recover it.\nAfter the checks, remove exactly that path (never a pattern) and keep it in the report.\nCopy the project\u002Finput tree and required imports; run every scenario that adds, deletes, empties,\nor retimes inputs, or deletes `obj`\u002Foutputs, with **the copy as working directory**. A backup is not\na verification copy, nor is an original project already under a temporary path. Compare original\nhashes before\u002Fafter; equal final hashes do not excuse intermediate mutation. A confirming build of\nthe repaired original must not delete outputs. If the copy cannot reproduce the environment, report\nblocked checks.\n\nFor input-set changes, prefer a persisted membership list written with `WriteLinesToFile` and\n`WriteOnlyWhenDifferent`, plus actual files in `Inputs`. A path list is not a content hash.\nVerify first\u002Funchanged builds, deletion, older addition, empty inputs, and missing-output recovery\non the copy. End the repair report, however brief, with three labeled explanations, not only a checklist:\n\n- **Cause:** state both blind spots: a deleted input vanishes from the timestamp comparison; an\n  added input older than the output never looks newer; either skips required regeneration.\n- **Mechanism:** identify the membership artifact and how its changes invalidate the output.\n  Unchanged membership preserves skips; actual file timestamps still catch ordinary edits.\n- **Checks:** list passed, failed, and not-run separately with the command or path used. \"None\n  failed\" requires every command to exit 0; an errored script, even if fixed and rerun, is listed\n  failed with its cause. If the main scenario passed but a later assertion failed, report both;\n  never summarize as verified.\n\nAfter a repair, rerun the original failing scenario and check affected dependents. If only a log\nis available, provide an evidence-backed proposed fix and say it was not applied or rebuilt.\nDo not turn a targeted failure investigation into solution-wide authoring cleanup.\n\n## 2. Diagnose and improve build performance\n\n**Goal:** measure the original workload, not an easier replacement.\n\nFor advice, give the verdict, decisive facts, and a concrete next step with equivalent successful\nbuilds and required outputs. Do not re-prove a supplied timeline or read references to restate it.\nDo not infer warm\u002Fno-op state or assign any part of a confounded timing gap to restore, cache, or\nsetting effects without isolating that cause.\n\n| Supplied evidence | Decision | Smallest useful follow-up |\n| --- | --- | --- |\n| Parallel target totals include overlapping dependency waits | Keep required references and parallelism. Cumulative waits can exceed both wall time and the duration of one dependency task; they do not prove CPU utilization or healthy scheduling. | Follow the supplied timeline to the dependency task holding up consumers. For `Csc`, inspect compiler inputs and invocation, analyzer\u002Fsource-generator timing, and whether compilation was expected for this workload. Measure CPU\u002Fnode utilization or I\u002FO contention if unknown; do not infer them from wait totals. Validate any change with equivalent successful builds and required outputs. |\n| Commands, restore policy, or starting input\u002Foutput states differ | Reject attribution to the setting, not the possibility of a real gain. | Give one matched old-setting\u002Fnew-setting experiment below, not a menu of different workloads or an invented setting name. |\n| Repeated successful runs have matched conditions and outputs | Accept the observed improvement for that workload; use the same summary statistic for both arms: `100 * (old - new) \u002F old`. | Report sample count and observed elapsed-time ranges, not an invented percentage uncertainty interval. Then state residual limits: small sample, one workload\u002Fmachine\u002FSDK, what restored starting state does and does not control, and no independent rerun. Do not require a checkout to acknowledge the supplied result. |\n\nWhen a minimal attribution experiment is needed, return **one two-arm table**, not alternatives:\n\n1. Bind the treatment to the user's identified setting and old\u002Fnew values. If unidentified, retain\n   literal `\u003Csetting>`, `\u003Cold>`, `\u003Cnew>` placeholders. Differing commands are confounds, not setting names.\n   Never substitute restore policy, Build\u002FRebuild, or cache state for an unidentified setting.\n2. Expand the **full original baseline command in both arms**. Only an explicitly identified\n   command-line treatment may change its own argument; otherwise vary its configured value.\n\n| Arm | Treatment, supplied or placeholder | Controlled invocation and workload |\n| --- | --- | --- |\n| A | `\u003Csetting> = \u003Cold>` | Full original baseline command; input and starting outputs exactly as supplied |\n| B | `\u003Csetting> = \u003Cnew>` | Same full command, input, and starting outputs; only the named treatment differs |\n\n3. Match non-treatment SDK, machine, configuration, instrumentation, target, restore policy,\n   and input\u002Foutput state exactly as supplied. Add no source edit the original workload lacked\n   (keep one it had in both arms). **Matching both arms is not enough if both replace the original\n   workload.** When they are controls, retain supplied Rebuild and timed restore; do not prime,\n   warm, or move work outside the timer unless the original workload already did.\n4. Alternate matched pairs; compare wall-time medians and observed ranges; check required outputs\n   and diagnostics. Scope the result to that workload. The table is the only experiment; the last\n   sentence states a validity check or residual limit, not an offer or variant.\n\nFor optimization work, establish the relevant successful baseline before changing one supported cause:\n\n| Unresolved measurement | Reference if needed |\n| --- | --- |\n| Cold-output, changed-input, no-change, restore\u002Fcache state, or Build versus Rebuild | [build-perf-baseline](references\u002Fbuild-perf-baseline.md) |\n| Unknown task cost, compiler\u002Fanalyzer\u002Freference\u002Frestore work, or overlapping waits | [build-perf-diagnostics](references\u002Fbuild-perf-diagnostics.md) |\n| Pre-target globs, imports, property evaluation, or excess project instances | [eval-performance](references\u002Feval-performance.md) |\n| Copies\u002Foutput I\u002FO, unchanged copies, or a modified destination | [copy-to-output-directory](references\u002Fcopy-to-output-directory.md) |\n| Unexpected regeneration\u002Fskips, added\u002Fremoved inputs, or missing outputs | [incremental-build](references\u002Fincremental-build.md) |\n\nStop when the suspected bottleneck is not supported by evidence, results fall within noise, or\ncorrectness regresses. Report missing measurements rather than manufacturing a complete baseline.\n\n## 3. Review build authoring\n\n**Goal:** preserve build contracts, not implicitly migrate frameworks, packages, languages, or project systems.\n\n**Check evaluation phases, not just import order.** Outside targets, properties\u002Fimports are\nevaluated before items. A framework set in the project body can be unavailable to an early\nproperty condition in `Directory.Build.props` but available to an item condition in that same\nfile. Move only the premature property assignment after its dependency; do not relocate an\nintentionally project-owned framework or a working item declaration. Preserve F# compile order\nand inspect SDK defaults before adding switches to suppress supposedly duplicated items.\n\n| Requested change | Reference if needed | Preserve |\n| --- | --- | --- |\n| Review\u002Fclean up project files, shared properties, item declarations, or custom targets | [msbuild-antipatterns](references\u002Fmsbuild-antipatterns.md) | Intentional overrides, F# source order, required imports, package assets, and actual input\u002Foutput contracts. |\n| Review\u002Fimprove hooks, imports, shared-file discovery, or NuGet build extensions | [extension-points](references\u002Fextension-points.md) | Prior hooks, evaluation order, direct\u002Ftransitive consumer behavior, and the packed layout. |\n| Restructure generation or copying as part of cleanup | [incremental-build](references\u002Fincremental-build.md) and [copy-to-output-directory](references\u002Fcopy-to-output-directory.md), as applicable | First-build and no-change behavior, invalidation, generated-item registration, and output completeness. |\n\nRecord the existing contract; a matching catalog pattern alone is not a defect. Leave correct code\nalone. Validate authorized changes against original configurations, consumers, and affected build behavior.\n\nKeep optional and required imports distinct, including inside aggregation files:\n\n```xml\n\u003CImport Project=\"optional.targets\" Condition=\"Exists('optional.targets')\" \u002F>\n\u003CImport Project=\"required.targets\" \u002F>\n```\n\nThe required import must load or fail, not silently skip. Explain why a condition on an entire\nmixed path list can suppress a valid required import; semicolon-separated imports themselves\nare supported. Check optional present\u002Fabsent crossed with required present\u002Fabsent, preserving\norder when both exist. When checks run, report the observed order and failure cases, not only\n\"verification passed.\" Do not replace configurable paths with hard-coded values unnecessarily.\n\nFor a packaged forwarder, keep these bindings separate:\n\n| Binding | Meaning |\n| --- | --- |\n| `NuspecFile` | Selects the XML manifest, possibly outside the project; not a payload mapping. |\n| `NuspecBasePath` | Base directory for the manifest's `file src` lookups on disk; it neither locates nor selects the manifest. |\n| Mapping `src` \u002F `target` | Reads the source file and emits its mapped archive path; does not implicitly ship the source path too. |\n| Consumer import | Resolves from the importing file inside the **package**, not source, feed, or the consumer's framework. |\n\nDo not substitute the manifest path for a mapping's `src`. For a no-change verdict, explain how\n`NuspecFile` selection, `NuspecBasePath` src lookup, mapping, packed target, and relative import connect, and why guarding\na required import would hide a broken package. If supplied package facts settle this, stop:\nno `Exists` guard, reorganization, or confirmatory rebuild\u002Frepack. Inspect artifacts only when\nverification is requested or contents remain unknown.\n\n## Shared evidence and safety\n\n- For analysis, use [MSBuild replay](references\u002Fbinlog-failure-analysis.md#replay-a-binary-log),\n  never binary-file text parsing. Replay success and replay duration are not the recorded\n  build's result or duration.\n- Resolve these files relative to this skill. Do not load the original plugin's skills or search\n  other installations\u002Fcheckouts. After a failed reference read, allow one listing of `references`\n  to distinguish a missing bundled file from a present-but-unreadable tool integration failure.\n  Report the error and reduced coverage; do not retry through shell commands or other readers,\n  and do not pretend unread guidance was followed. Never work around a policy denial.\n- Do not clean outputs\u002Fcaches, stop shared build servers, disable diagnostics, change SDKs, or\n  serialize builds as generic fixes. Scope any necessary destructive experiment to approved,\n  owned outputs. Keep binary and replayed logs local unless sharing is authorized.\n- Distinguish recorded facts from hypotheses. Missing source, log detail, tools, or platform\n  support must be reported explicitly, not replaced with assumed values or invented verification.\n\n## Completion\n\nAdvice: verdict, decisive evidence, necessary next measurement; no manufactured verification.\nRepository work: cause\u002Fdecision, minimal change (or no change), and exact successful, failed,\nand not-run checks. Performance claims also need comparable measurements and uncertainty.\nScale length to the task, but never drop a required report field.\n","# MSBuild troubleshooting\n\nFor advice or static review, answer from the supplied XML, package facts, or measurements when\nthey settle the question: no reference reads, checkout discovery, commands, or invented verification.\nFor requested work, start at the supplied project or artifact; discover only what the next decision\nneeds. Read a reference only for a specific unresolved question. References are not invocable skills.\n\n## Start with the task and evidence\n\nBefore editing, follow repository instructions and inspect the project\u002Fimports. Preserve the original\ncommand, working directory, SDK, configuration, target framework, runtime identifier, global properties,\nand target. Ask only for consequential information that cannot be discovered.\n\nAn existing `.binlog` can be the only available artifact. Analyze it before requesting a new\nbuild; paths inside it do not prove a checkout exists locally.\n\nFor a mixed request, fix correctness before measuring successful builds, and keep authoring review\nseparate from a performance experiment. A failing test assertion after a successful build is not\nan MSBuild failure.\n\n**Capture only:** choose an unused artifact path under the supplied workspace, unless the user\nspecified another artifact directory. Do not put the only deliverable in a shared\u002Fglobal\ntemporary directory where workspace artifact collection will miss it, or stage\u002Fcommit the log.\nAppend the binary logger to the exact supplied command, run it once, and save its original\nexit code before checking the new log is nonempty.\nReport the artifact path and original exit code, then stop: no replay, diagnosis, or repair.\nRead [capture details](references\u002Fbinlog-generation.md) only for an unresolved wrapper,\nlogger-option, toolset, or privacy question.\n\n## 1. Troubleshoot build issues\n\n**Goal:** identify the independent root causes and make the smallest repair, not a broad cleanup.\n\n| Situation | Reference if needed | Action |\n| --- | --- | --- |\n| A build failed and a binary log exists | [binlog-failure-analysis](references\u002Fbinlog-failure-analysis.md) | Replay the log with MSBuild; connect errors to the responsible project instance, target, and task. Separate root causes from cascading failures. |\n| The failure needs evidence and no matching log exists | [binlog-generation](references\u002Fbinlog-generation.md), then [failure analysis](references\u002Fbinlog-failure-analysis.md) | Capture the original invocation once and verify the artifact. Analyze it only when requested. |\n| A project\u002Fbuild file has incorrect conditions, items, properties, or output paths | [msbuild-antipatterns](references\u002Fmsbuild-antipatterns.md) | Select the relevant catalog entries and check their exceptions before changing anything. |\n| Imports or build hooks are missing, overwritten, or run in the wrong order | [extension-points](references\u002Fextension-points.md) | Inspect the import contract, discovery order, and packed NuGet layout rather than hiding a required failure. |\n| Outputs are stale or required work is skipped | [incremental-build](references\u002Fincremental-build.md) | Track input-set membership as well as file timestamps; apply the repair contract below. |\n\nFor build-wiring-only work, generator and source inputs are **read-only throughout**, not restored\nafter tests; edit the original only as the requested repair requires.\nAllocate disposable scratch as a uniquely named directory **outside the project tree**, normally\nthe OS temporary directory from `mktemp -d`; a copy inside the project can be matched by SDK\ndefault globs and break the later confirming build. Print the path once and write every copy, log,\nand hash under it: no fixed leaf names, pointer files, pre-deleting, or globbing to recover it.\nAfter the checks, remove exactly that path (never a pattern) and keep it in the report.\nCopy the project\u002Finput tree and required imports; run every scenario that adds, deletes, empties,\nor retimes inputs, or deletes `obj`\u002Foutputs, with **the copy as working directory**. A backup is not\na verification copy, nor is an original project already under a temporary path. Compare original\nhashes before\u002Fafter; equal final hashes do not excuse intermediate mutation. A confirming build of\nthe repaired original must not delete outputs. If the copy cannot reproduce the environment, report\nblocked checks.\n\nFor input-set changes, prefer a persisted membership list written with `WriteLinesToFile` and\n`WriteOnlyWhenDifferent`, plus actual files in `Inputs`. A path list is not a content hash.\nVerify first\u002Funchanged builds, deletion, older addition, empty inputs, and missing-output recovery\non the copy. End the repair report, however brief, with three labeled explanations, not only a checklist:\n\n- **Cause:** state both blind spots: a deleted input vanishes from the timestamp comparison; an\n  added input older than the output never looks newer; either skips required regeneration.\n- **Mechanism:** identify the membership artifact and how its changes invalidate the output.\n  Unchanged membership preserves skips; actual file timestamps still catch ordinary edits.\n- **Checks:** list passed, failed, and not-run separately with the command or path used. \"None\n  failed\" requires every command to exit 0; an errored script, even if fixed and rerun, is listed\n  failed with its cause. If the main scenario passed but a later assertion failed, report both;\n  never summarize as verified.\n\nAfter a repair, rerun the original failing scenario and check affected dependents. If only a log\nis available, provide an evidence-backed proposed fix and say it was not applied or rebuilt.\nDo not turn a targeted failure investigation into solution-wide authoring cleanup.\n\n## 2. Diagnose and improve build performance\n\n**Goal:** measure the original workload, not an easier replacement.\n\nFor advice, give the verdict, decisive facts, and a concrete next step with equivalent successful\nbuilds and required outputs. Do not re-prove a supplied timeline or read references to restate it.\nDo not infer warm\u002Fno-op state or assign any part of a confounded timing gap to restore, cache, or\nsetting effects without isolating that cause.\n\n| Supplied evidence | Decision | Smallest useful follow-up |\n| --- | --- | --- |\n| Parallel target totals include overlapping dependency waits | Keep required references and parallelism. Cumulative waits can exceed both wall time and the duration of one dependency task; they do not prove CPU utilization or healthy scheduling. | Follow the supplied timeline to the dependency task holding up consumers. For `Csc`, inspect compiler inputs and invocation, analyzer\u002Fsource-generator timing, and whether compilation was expected for this workload. Measure CPU\u002Fnode utilization or I\u002FO contention if unknown; do not infer them from wait totals. Validate any change with equivalent successful builds and required outputs. |\n| Commands, restore policy, or starting input\u002Foutput states differ | Reject attribution to the setting, not the possibility of a real gain. | Give one matched old-setting\u002Fnew-setting experiment below, not a menu of different workloads or an invented setting name. |\n| Repeated successful runs have matched conditions and outputs | Accept the observed improvement for that workload; use the same summary statistic for both arms: `100 * (old - new) \u002F old`. | Report sample count and observed elapsed-time ranges, not an invented percentage uncertainty interval. Then state residual limits: small sample, one workload\u002Fmachine\u002FSDK, what restored starting state does and does not control, and no independent rerun. Do not require a checkout to acknowledge the supplied result. |\n\nWhen a minimal attribution experiment is needed, return **one two-arm table**, not alternatives:\n\n1. Bind the treatment to the user's identified setting and old\u002Fnew values. If unidentified, retain\n   literal `\u003Csetting>`, `\u003Cold>`, `\u003Cnew>` placeholders. Differing commands are confounds, not setting names.\n   Never substitute restore policy, Build\u002FRebuild, or cache state for an unidentified setting.\n2. Expand the **full original baseline command in both arms**. Only an explicitly identified\n   command-line treatment may change its own argument; otherwise vary its configured value.\n\n| Arm | Treatment, supplied or placeholder | Controlled invocation and workload |\n| --- | --- | --- |\n| A | `\u003Csetting> = \u003Cold>` | Full original baseline command; input and starting outputs exactly as supplied |\n| B | `\u003Csetting> = \u003Cnew>` | Same full command, input, and starting outputs; only the named treatment differs |\n\n3. Match non-treatment SDK, machine, configuration, instrumentation, target, restore policy,\n   and input\u002Foutput state exactly as supplied. Add no source edit the original workload lacked\n   (keep one it had in both arms). **Matching both arms is not enough if both replace the original\n   workload.** When they are controls, retain supplied Rebuild and timed restore; do not prime,\n   warm, or move work outside the timer unless the original workload already did.\n4. Alternate matched pairs; compare wall-time medians and observed ranges; check required outputs\n   and diagnostics. Scope the result to that workload. The table is the only experiment; the last\n   sentence states a validity check or residual limit, not an offer or variant.\n\nFor optimization work, establish the relevant successful baseline before changing one supported cause:\n\n| Unresolved measurement | Reference if needed |\n| --- | --- |\n| Cold-output, changed-input, no-change, restore\u002Fcache state, or Build versus Rebuild | [build-perf-baseline](references\u002Fbuild-perf-baseline.md) |\n| Unknown task cost, compiler\u002Fanalyzer\u002Freference\u002Frestore work, or overlapping waits | [build-perf-diagnostics](references\u002Fbuild-perf-diagnostics.md) |\n| Pre-target globs, imports, property evaluation, or excess project instances | [eval-performance](references\u002Feval-performance.md) |\n| Copies\u002Foutput I\u002FO, unchanged copies, or a modified destination | [copy-to-output-directory](references\u002Fcopy-to-output-directory.md) |\n| Unexpected regeneration\u002Fskips, added\u002Fremoved inputs, or missing outputs | [incremental-build](references\u002Fincremental-build.md) |\n\nStop when the suspected bottleneck is not supported by evidence, results fall within noise, or\ncorrectness regresses. Report missing measurements rather than manufacturing a complete baseline.\n\n## 3. Review build authoring\n\n**Goal:** preserve build contracts, not implicitly migrate frameworks, packages, languages, or project systems.\n\n**Check evaluation phases, not just import order.** Outside targets, properties\u002Fimports are\nevaluated before items. A framework set in the project body can be unavailable to an early\nproperty condition in `Directory.Build.props` but available to an item condition in that same\nfile. Move only the premature property assignment after its dependency; do not relocate an\nintentionally project-owned framework or a working item declaration. Preserve F# compile order\nand inspect SDK defaults before adding switches to suppress supposedly duplicated items.\n\n| Requested change | Reference if needed | Preserve |\n| --- | --- | --- |\n| Review\u002Fclean up project files, shared properties, item declarations, or custom targets | [msbuild-antipatterns](references\u002Fmsbuild-antipatterns.md) | Intentional overrides, F# source order, required imports, package assets, and actual input\u002Foutput contracts. |\n| Review\u002Fimprove hooks, imports, shared-file discovery, or NuGet build extensions | [extension-points](references\u002Fextension-points.md) | Prior hooks, evaluation order, direct\u002Ftransitive consumer behavior, and the packed layout. |\n| Restructure generation or copying as part of cleanup | [incremental-build](references\u002Fincremental-build.md) and [copy-to-output-directory](references\u002Fcopy-to-output-directory.md), as applicable | First-build and no-change behavior, invalidation, generated-item registration, and output completeness. |\n\nRecord the existing contract; a matching catalog pattern alone is not a defect. Leave correct code\nalone. Validate authorized changes against original configurations, consumers, and affected build behavior.\n\nKeep optional and required imports distinct, including inside aggregation files:\n\n```xml\n\u003CImport Project=\"optional.targets\" Condition=\"Exists('optional.targets')\" \u002F>\n\u003CImport Project=\"required.targets\" \u002F>\n```\n\nThe required import must load or fail, not silently skip. Explain why a condition on an entire\nmixed path list can suppress a valid required import; semicolon-separated imports themselves\nare supported. Check optional present\u002Fabsent crossed with required present\u002Fabsent, preserving\norder when both exist. When checks run, report the observed order and failure cases, not only\n\"verification passed.\" Do not replace configurable paths with hard-coded values unnecessarily.\n\nFor a packaged forwarder, keep these bindings separate:\n\n| Binding | Meaning |\n| --- | --- |\n| `NuspecFile` | Selects the XML manifest, possibly outside the project; not a payload mapping. |\n| `NuspecBasePath` | Base directory for the manifest's `file src` lookups on disk; it neither locates nor selects the manifest. |\n| Mapping `src` \u002F `target` | Reads the source file and emits its mapped archive path; does not implicitly ship the source path too. |\n| Consumer import | Resolves from the importing file inside the **package**, not source, feed, or the consumer's framework. |\n\nDo not substitute the manifest path for a mapping's `src`. For a no-change verdict, explain how\n`NuspecFile` selection, `NuspecBasePath` src lookup, mapping, packed target, and relative import connect, and why guarding\na required import would hide a broken package. If supplied package facts settle this, stop:\nno `Exists` guard, reorganization, or confirmatory rebuild\u002Frepack. Inspect artifacts only when\nverification is requested or contents remain unknown.\n\n## Shared evidence and safety\n\n- For analysis, use [MSBuild replay](references\u002Fbinlog-failure-analysis.md#replay-a-binary-log),\n  never binary-file text parsing. Replay success and replay duration are not the recorded\n  build's result or duration.\n- Resolve these files relative to this skill. Do not load the original plugin's skills or search\n  other installations\u002Fcheckouts. After a failed reference read, allow one listing of `references`\n  to distinguish a missing bundled file from a present-but-unreadable tool integration failure.\n  Report the error and reduced coverage; do not retry through shell commands or other readers,\n  and do not pretend unread guidance was followed. Never work around a policy denial.\n- Do not clean outputs\u002Fcaches, stop shared build servers, disable diagnostics, change SDKs, or\n  serialize builds as generic fixes. Scope any necessary destructive experiment to approved,\n  owned outputs. Keep binary and replayed logs local unless sharing is authorized.\n- Distinguish recorded facts from hypotheses. Missing source, log detail, tools, or platform\n  support must be reported explicitly, not replaced with assumed values or invented verification.\n\n## Completion\n\nAdvice: verdict, decisive evidence, necessary next measurement; no manufactured verification.\nRepository work: cause\u002Fdecision, minimal change (or no change), and exact successful, failed,\nand not-run checks. Performance claims also need comparable measurements and uncertainty.\nScale length to the task, but never drop a required report field.\n",{"name":5,"license":15,"description":7},"main","367e97f05fa5a6d7068734d340cfa415690d8a33","external-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild",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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add managedcode\u002Fdotnet-skills --skill msbuild",{"tool":64,"command":65},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill msbuild",{"tool":67,"command":68},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill msbuild","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002FSKILL.md",true,[72,78,82,86,90,94,98,102,106,110,114,118],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fantipatterns\u002Fadditional-antipatterns.md","REFERENCE","参考文档",13148,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fantipatterns\u002Fadditional-antipatterns.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fantipatterns\u002Fincremental-build-inputs-outputs.md",3040,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fantipatterns\u002Fincremental-build-inputs-outputs.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fantipatterns\u002Fprivate-assets.md",1545,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fantipatterns\u002Fprivate-assets.md",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fbinlog-failure-analysis.md",4891,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fbinlog-failure-analysis.md",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fbinlog-generation.md",3378,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fbinlog-generation.md",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fbuild-perf-baseline.md",19481,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fbuild-perf-baseline.md",{"path":99,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fbuild-perf-diagnostics.md",14226,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fbuild-perf-diagnostics.md",{"path":103,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fcopy-to-output-directory.md",8144,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fcopy-to-output-directory.md",{"path":107,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Feval-performance.md",8638,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Feval-performance.md",{"path":111,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fextension-points.md",13767,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fextension-points.md",{"path":115,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002Fincremental-build.md",17661,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fincremental-build.md",{"path":119,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Fmsbuild-antipatterns.md",16790,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet\u002Fskills\u002Fmsbuild\u002Freferences\u002Fmsbuild-antipatterns.md",[123,153,178,210,220,246],{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":135,"publishedAt":43},"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",[129,134],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[136,137,138,139,27,140,141,142,38,143,144,145,146,147,148,30,149,150,151,152],"xtwitter scraper","browser automation","workflows","run","browser","search","repository","Media","api client","access","edit","unrelated","webhooks","social","commands","modeling","webhook",{"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":165,"publishedAt":43},"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",[159,162],{"categoryNo":160,"categoryName":161,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":163,"categoryName":164,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[155,166,167,138,168,139,142,169,170,171,146,172,147,30,173,174,175,176,150,177],"writing","performance","tasks","data","parsing","parser","context","do","writer","options","project","high-performance",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":43},"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",[],[185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209],"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","when",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":216,"publishedAt":43},"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",[],[212,197,30,217,218,205,219],"semantic","razor","inspection",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":226,"publishedAt":43},"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",[],[227,228,229,230,166,231,232,233,234,235,236,197,41,237,238,239,173,240,241,242,243,205,244,245,209],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":247,"name":248,"nameZh":6,"description":249,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":250,"categories":251,"keywords":254,"publishedAt":43},"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",[252,253],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[38,255,256,257,139,258,192,227,197,238,239,173,259,260,261,262,243,205,263],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]