[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WQYPE9JVYV8HTFHC0ZMX36":3,"skill-same:01M6WQYPE9JVYV8HTFHC0ZMX36":76},{"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":18,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6WQYPE9JVYV8HTFHC0ZMX36","find-repeated-work-within-one-build",null,"Use ONLY for auditing executed-task counts or batching\u002Fhoisting costs within ONE MSBuild invocation: per-project Exec, duplicate dependency builds, per-item generators, run-once races. NEVER load for evaluation-only global-property variants with once-only target\u002Ftask execution, idle-node\u002Fserial-chain investigations, second\u002Funchanged builds, restores across commands, required-variant bin\u002Fobj collisions or unranked slowness. Do not load to check scope or replace an unavailable specialist; answer directly.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",514,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FOfficial-DotNet-MSBuild\u002Fskills\u002Ffind-repeated-work-within-one-build\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"work","find repeated work within one build","find","build","across","OBJ","investigations","second","variants","for","scope","chain","commands","project","run","do","dependency","only","never","node","answer directly","Evaluation","2026-11-10 10:12:30",false,"---\nname: find-repeated-work-within-one-build\ndescription: \"Use ONLY for auditing executed-task counts or batching\u002Fhoisting costs within ONE MSBuild invocation: per-project Exec, duplicate dependency builds, per-item generators, run-once races. NEVER load for evaluation-only global-property variants with once-only target\u002Ftask execution, idle-node\u002Fserial-chain investigations, second\u002Funchanged builds, restores across commands, required-variant bin\u002Fobj collisions or unranked slowness. Do not load to check scope or replace an unavailable specialist; answer directly.\"\nlicense: MIT\n---\n\n# Find Repeated Work Within One Build\n\nMSBuild runs targets once per project instance. Work that does not depend on the project, but sits in `Directory.Build.targets` or a shared target, therefore runs once per project: a `git rev-parse` in 40 projects is 40 process launches. A project built with different global properties is a different instance, so a shared library can compile several times in one build. The binlog's `N calls` column shows both. This skill finds the repeats, separates them from work that is legitimately per project, and removes only what is safe to remove.\n\n## When to Use\n\n- The same `Exec` or task (version stamping, tool probes, file generation) runs in every project\n- Target or Task Performance Summary shows a call count far above the number of projects that need the work\n- The same project executes its build targets repeatedly under global-property sets that do not change its outputs\n- An `Exec` spawns one process per item in a list\n- A \"run once per build\" guard (`Exists` check, flag property) still runs repeatedly or fails with file-in-use errors under `-m`\n\n## When Not to Use\n\n- Targets that run again on a second, unchanged build: use `incremental-build`\n- Slow evaluation before any target runs: use `eval-performance`\n- Required project variants colliding in shared bin\u002Fobj directories: use `check-bin-obj-clash`\n- Idle nodes or a serial dependency chain: use `build-parallelism`\n- NuGet restore repeated across separate `dotnet restore`, `dotnet build` and `dotnet test` commands: use `eliminate-redundant-restores`\n- Unranked \"why is my build slow\": start with `build-perf-baseline`, then `build-perf-diagnostics`\n\n## Workflow\n\n### Step 1: Count executions\n\nUse a supplied performance summary with execution counts as valid input; a raw binlog is not required. If the user cannot run the build or forbids execution or new logs, work from the summary and repository files. Mark unavailable timing or overlap evidence `unknown` and proposed fixes `not validated`; do not execute a build or collect another log.\n\nIf neither usable execution counts nor a binlog is supplied, capture one only when build execution is available and permitted. Use the `binlog-generation` skill: add `\u002Fbl:{}` to the original MSBuild invocation, preserving its configuration, global properties, parallelism and restore behavior. In PowerShell, quote the complete switch as `'-bl:{}'`. If a script drives the build, instrument its underlying MSBuild invocation rather than replace it with a different build command. Confirm the binlog exists and record its path. If capture is not permitted, report the missing evidence instead of running the build.\n\nFor an available binlog, prefer the bundled **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace). Discover its available tools and query project, target and task execution counts and timings from that binlog. Do not read the binary file as text.\n\nIf MCP is unavailable or its tools do not expose execution counts, replay the captured binlog to a text performance summary and read the `N calls` column of the Target and Task Performance Summaries and the Project Performance Summary:\n\n```bash\ndotnet msbuild build.binlog -noconlog \"-flp:v=diag;logfile=full.log;performancesummary\"\n```\n\nCount required distinct computations, not just consumers. Derive the expected count separately for each kind of work: `Csc` normally runs once per project and target framework, whereas copy-local work scales with files and can run in several targets. Project count times TFMs is not a universal ceiling for every task; leave an unsupported expected count `unknown` rather than claiming that a larger count is redundant. A multi-targeted project can legitimately show one outer build plus one inner build per TFM, so four project calls for three TFMs are not automatically duplicates. Account for required TFMs and global properties before investigating extra instances.\n\nAn invariant tool-version or revision probe needs one computation per equivalent input scope, even when several projects consume its result. A target condition restricting it to a subset of projects does not make the result per-project. Confirm that inputs, working directories, relevant properties and output semantics are equivalent; identical command text alone does not prove invariance. In particular, fresh per-project signing identities are intentionally nondeterministic: do not cache, reuse or share one identity across projects or builds. Keep each required execution unless a documented tool mode can produce all the distinct results without changing the contract.\n\n### Step 2: Classify each candidate\n\n| Pattern | Signal | Fix | Never |\n|---|---|---|---|\n| Invariant per-project `Exec` or task (commit hash, tool version, generated file) | Multiple consumers need the same deterministic result under equivalent inputs | Compute it once outside the per-project targets: the build script passes `-p:Name=value`, or a pre-build step or orchestrator target runs first | A flag property or `Exists(stamp)` guard: properties are per project instance and `-m` worker nodes are separate processes, so the guard does not dedupe and races |\n| Same project built several times | One project path with N calls and different global properties (for example `Properties=\"ComponentName=%(Component.Filename)\"` on an `MSBuild` task). Any extra global property, even an unused one, creates a new instance | Stop passing the property, or add `GlobalPropertiesToRemove` metadata on the shared `ProjectReference` (`RemoveProperties` on the `MSBuild` task) | Removing a property the project actually reads |\n| One process per item (`Exec` batched on `%(Item.Identity)`) | `Exec` calls equal the item count | One invocation that takes a list or response file, after checking the tool supports it; keep `Inputs`\u002F`Outputs` (with a 1:1 transform MSBuild still passes only the stale items into the target) | Dropping `Inputs`\u002F`Outputs` while merging |\n| Legitimate per-project, per-TFM or per-item work | Count matches the required project, framework or output-item scopes | Leave it alone | Applying one count ceiling to unrelated task kinds |\n\n### Step 3: Size the win\n\nFor eliminated invariant computations, estimate avoidable aggregate task time as `(calls - expected) x average ms`. Per-item batching does not eliminate the required input processing: estimate `(old process starts - new process starts) x startup ms`, retaining every input's processing cost and any required metadata groups. Account for additional list\u002Fbatch overhead when known. If startup cost is unavailable, mark that estimate unknown rather than treating the entire average task duration as removable.\n\nWall-clock saving depends on actual overlap and the critical path. Batched per-item `Exec` calls in one target run sequentially on one node, so avoided startup time is not divided by unrelated busy nodes. Only divide by effective parallelism when the removed work actually overlaps across nodes. Use the binlog timeline to establish overlap, and mark wall-clock savings unknown when that evidence is missing. Work off the critical path can yield no wall-clock gain. For performance-only changes, if even the aggregate upper bound is below about 1% of build wall-clock, report it as not worth changing. Correctness races still need a fix regardless of the timing gain.\n\nFor a cost-based no-change recommendation, show the avoidable aggregate-time bound and, when build elapsed time is supplied, `100 x bound \u002F elapsed` as an upper-bound percentage, not a measured wall-clock gain. Distinguish work that is technically redundant but too cheap to change from work that must remain distinct.\n\n### Step 4: Fix without changing behavior\n\n1. Keep the value available before its first consumer.\n2. Keep a fallback `Condition=\"'$(X)' == ''\"` for builds without the shared value. Imported or environment properties can satisfy it too; the value need not be global. Child builds inherit existing global properties unless removed, but not ordinary properties computed in their parent. Forward a parent-computed result through the `MSBuild` task's `Properties`, or load the shared value in each child before the fallback; otherwise each child can execute its own fallback.\n3. Define the computation in one place.\n4. Preserve generated-file timestamps when content is unchanged. Use a write-if-different generator, or generate to a temporary file and replace only on content change; deduplication must not force dependent recompilation on an unchanged rerun.\n\n```xml\n\u003C!-- Before: every project launches git -->\n\u003CTarget Name=\"StampCommit\" BeforeTargets=\"CoreCompile\">\n  \u003CExec Command=\"git rev-parse HEAD\" ConsoleToMSBuild=\"true\">\n    \u003COutput TaskParameter=\"ConsoleOutput\" PropertyName=\"GitCommit\" \u002F>\n  \u003C\u002FExec>\n\u003C\u002FTarget>\n\n\u003C!-- After: the build script computes the hash once and passes -p:GitCommit=\u003Chash> -->\n\u003CTarget Name=\"StampCommit\" BeforeTargets=\"CoreCompile\">\n  \u003CExec Command=\"git rev-parse HEAD\" ConsoleToMSBuild=\"true\" Condition=\"'$(GitCommit)' == ''\">\n    \u003COutput TaskParameter=\"ConsoleOutput\" PropertyName=\"GitCommit\" \u002F>\n  \u003C\u002FExec>\n\u003C\u002FTarget>\n```\n\nIf Source Link already supplies `SourceRevisionId`, it can replace an `Exec` only when it is available before the consumer and preserves the existing stamp representation. `SourceRevisionId` normally contains the full commit ID; do not substitute it for `git rev-parse --short HEAD` without retaining the original abbreviation contract.\n\n### Step 5: Validate and report truthfully\n\n1. When execution is available and permitted, capture a new binlog of the same invocation. Calls must have dropped to the expected count. Otherwise, do not run the build or collect another log; report the fix as proposed and not validated.\n2. Confirm outputs are unchanged (the stamped value, generated file contents). For generated sources, also check that an unchanged second build stays incremental.\n3. Report timing as the median of at least three runs; if you could not run the build, say \"not validated\".\n\n## Output\n\nFor on-target requests, keep the answer proportional to the evidence: a compact findings table with at least one row, a short explanation of the decisive computation or preservation constraint, and a standalone, unformatted `Verdict:` line. Do not bold the line or append it to a paragraph. Use `unknown` for unavailable timing or critical-path evidence; distinguish estimated aggregate task time from measured wall-clock savings. If the contract requires every execution, report zero avoidable time even when task durations are unknown.\n\n| Work | Calls | Expected | Avoidable ms | Cause | Fix | On critical path? |\n|---|---|---|---|---|---|---|\n\nAfter verification: `Verdict: removed N repeated executions, measured wall-clock saving X s`.\n\nWithout verification: `Verdict: proposed removal of N repeated executions; estimated task-time saving X s; wall-clock not validated`.\n\nWhen no change is worthwhile: `Verdict: no repeated work worth changing`.\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---|---|\n| Treating `Csc` or copy-local counts as waste | Compare `Csc` with projects times TFMs, and copies with required files and targets; do not assume both have the same expected count |\n| Guarding with `Exists(file)` or a flag property | Move the work out of the per-project path |\n| Assuming parent-local properties are inherited by child builds | Forward the shared value explicitly or load it in each child before the fallback; otherwise the fallback repeats in those children. Existing global properties are already inherited unless removed. |\n| Claiming a saving from total task time | Check actual overlap and the critical path; do not divide sequential work by unrelated busy nodes |\n| Merging per-item `Exec` and losing incrementality | Keep `Inputs` and `Outputs` on the target |\n","# Find Repeated Work Within One Build\n\nMSBuild runs targets once per project instance. Work that does not depend on the project, but sits in `Directory.Build.targets` or a shared target, therefore runs once per project: a `git rev-parse` in 40 projects is 40 process launches. A project built with different global properties is a different instance, so a shared library can compile several times in one build. The binlog's `N calls` column shows both. This skill finds the repeats, separates them from work that is legitimately per project, and removes only what is safe to remove.\n\n## When to Use\n\n- The same `Exec` or task (version stamping, tool probes, file generation) runs in every project\n- Target or Task Performance Summary shows a call count far above the number of projects that need the work\n- The same project executes its build targets repeatedly under global-property sets that do not change its outputs\n- An `Exec` spawns one process per item in a list\n- A \"run once per build\" guard (`Exists` check, flag property) still runs repeatedly or fails with file-in-use errors under `-m`\n\n## When Not to Use\n\n- Targets that run again on a second, unchanged build: use `incremental-build`\n- Slow evaluation before any target runs: use `eval-performance`\n- Required project variants colliding in shared bin\u002Fobj directories: use `check-bin-obj-clash`\n- Idle nodes or a serial dependency chain: use `build-parallelism`\n- NuGet restore repeated across separate `dotnet restore`, `dotnet build` and `dotnet test` commands: use `eliminate-redundant-restores`\n- Unranked \"why is my build slow\": start with `build-perf-baseline`, then `build-perf-diagnostics`\n\n## Workflow\n\n### Step 1: Count executions\n\nUse a supplied performance summary with execution counts as valid input; a raw binlog is not required. If the user cannot run the build or forbids execution or new logs, work from the summary and repository files. Mark unavailable timing or overlap evidence `unknown` and proposed fixes `not validated`; do not execute a build or collect another log.\n\nIf neither usable execution counts nor a binlog is supplied, capture one only when build execution is available and permitted. Use the `binlog-generation` skill: add `\u002Fbl:{}` to the original MSBuild invocation, preserving its configuration, global properties, parallelism and restore behavior. In PowerShell, quote the complete switch as `'-bl:{}'`. If a script drives the build, instrument its underlying MSBuild invocation rather than replace it with a different build command. Confirm the binlog exists and record its path. If capture is not permitted, report the missing evidence instead of running the build.\n\nFor an available binlog, prefer the bundled **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace). Discover its available tools and query project, target and task execution counts and timings from that binlog. Do not read the binary file as text.\n\nIf MCP is unavailable or its tools do not expose execution counts, replay the captured binlog to a text performance summary and read the `N calls` column of the Target and Task Performance Summaries and the Project Performance Summary:\n\n```bash\ndotnet msbuild build.binlog -noconlog \"-flp:v=diag;logfile=full.log;performancesummary\"\n```\n\nCount required distinct computations, not just consumers. Derive the expected count separately for each kind of work: `Csc` normally runs once per project and target framework, whereas copy-local work scales with files and can run in several targets. Project count times TFMs is not a universal ceiling for every task; leave an unsupported expected count `unknown` rather than claiming that a larger count is redundant. A multi-targeted project can legitimately show one outer build plus one inner build per TFM, so four project calls for three TFMs are not automatically duplicates. Account for required TFMs and global properties before investigating extra instances.\n\nAn invariant tool-version or revision probe needs one computation per equivalent input scope, even when several projects consume its result. A target condition restricting it to a subset of projects does not make the result per-project. Confirm that inputs, working directories, relevant properties and output semantics are equivalent; identical command text alone does not prove invariance. In particular, fresh per-project signing identities are intentionally nondeterministic: do not cache, reuse or share one identity across projects or builds. Keep each required execution unless a documented tool mode can produce all the distinct results without changing the contract.\n\n### Step 2: Classify each candidate\n\n| Pattern | Signal | Fix | Never |\n|---|---|---|---|\n| Invariant per-project `Exec` or task (commit hash, tool version, generated file) | Multiple consumers need the same deterministic result under equivalent inputs | Compute it once outside the per-project targets: the build script passes `-p:Name=value`, or a pre-build step or orchestrator target runs first | A flag property or `Exists(stamp)` guard: properties are per project instance and `-m` worker nodes are separate processes, so the guard does not dedupe and races |\n| Same project built several times | One project path with N calls and different global properties (for example `Properties=\"ComponentName=%(Component.Filename)\"` on an `MSBuild` task). Any extra global property, even an unused one, creates a new instance | Stop passing the property, or add `GlobalPropertiesToRemove` metadata on the shared `ProjectReference` (`RemoveProperties` on the `MSBuild` task) | Removing a property the project actually reads |\n| One process per item (`Exec` batched on `%(Item.Identity)`) | `Exec` calls equal the item count | One invocation that takes a list or response file, after checking the tool supports it; keep `Inputs`\u002F`Outputs` (with a 1:1 transform MSBuild still passes only the stale items into the target) | Dropping `Inputs`\u002F`Outputs` while merging |\n| Legitimate per-project, per-TFM or per-item work | Count matches the required project, framework or output-item scopes | Leave it alone | Applying one count ceiling to unrelated task kinds |\n\n### Step 3: Size the win\n\nFor eliminated invariant computations, estimate avoidable aggregate task time as `(calls - expected) x average ms`. Per-item batching does not eliminate the required input processing: estimate `(old process starts - new process starts) x startup ms`, retaining every input's processing cost and any required metadata groups. Account for additional list\u002Fbatch overhead when known. If startup cost is unavailable, mark that estimate unknown rather than treating the entire average task duration as removable.\n\nWall-clock saving depends on actual overlap and the critical path. Batched per-item `Exec` calls in one target run sequentially on one node, so avoided startup time is not divided by unrelated busy nodes. Only divide by effective parallelism when the removed work actually overlaps across nodes. Use the binlog timeline to establish overlap, and mark wall-clock savings unknown when that evidence is missing. Work off the critical path can yield no wall-clock gain. For performance-only changes, if even the aggregate upper bound is below about 1% of build wall-clock, report it as not worth changing. Correctness races still need a fix regardless of the timing gain.\n\nFor a cost-based no-change recommendation, show the avoidable aggregate-time bound and, when build elapsed time is supplied, `100 x bound \u002F elapsed` as an upper-bound percentage, not a measured wall-clock gain. Distinguish work that is technically redundant but too cheap to change from work that must remain distinct.\n\n### Step 4: Fix without changing behavior\n\n1. Keep the value available before its first consumer.\n2. Keep a fallback `Condition=\"'$(X)' == ''\"` for builds without the shared value. Imported or environment properties can satisfy it too; the value need not be global. Child builds inherit existing global properties unless removed, but not ordinary properties computed in their parent. Forward a parent-computed result through the `MSBuild` task's `Properties`, or load the shared value in each child before the fallback; otherwise each child can execute its own fallback.\n3. Define the computation in one place.\n4. Preserve generated-file timestamps when content is unchanged. Use a write-if-different generator, or generate to a temporary file and replace only on content change; deduplication must not force dependent recompilation on an unchanged rerun.\n\n```xml\n\u003C!-- Before: every project launches git -->\n\u003CTarget Name=\"StampCommit\" BeforeTargets=\"CoreCompile\">\n  \u003CExec Command=\"git rev-parse HEAD\" ConsoleToMSBuild=\"true\">\n    \u003COutput TaskParameter=\"ConsoleOutput\" PropertyName=\"GitCommit\" \u002F>\n  \u003C\u002FExec>\n\u003C\u002FTarget>\n\n\u003C!-- After: the build script computes the hash once and passes -p:GitCommit=\u003Chash> -->\n\u003CTarget Name=\"StampCommit\" BeforeTargets=\"CoreCompile\">\n  \u003CExec Command=\"git rev-parse HEAD\" ConsoleToMSBuild=\"true\" Condition=\"'$(GitCommit)' == ''\">\n    \u003COutput TaskParameter=\"ConsoleOutput\" PropertyName=\"GitCommit\" \u002F>\n  \u003C\u002FExec>\n\u003C\u002FTarget>\n```\n\nIf Source Link already supplies `SourceRevisionId`, it can replace an `Exec` only when it is available before the consumer and preserves the existing stamp representation. `SourceRevisionId` normally contains the full commit ID; do not substitute it for `git rev-parse --short HEAD` without retaining the original abbreviation contract.\n\n### Step 5: Validate and report truthfully\n\n1. When execution is available and permitted, capture a new binlog of the same invocation. Calls must have dropped to the expected count. Otherwise, do not run the build or collect another log; report the fix as proposed and not validated.\n2. Confirm outputs are unchanged (the stamped value, generated file contents). For generated sources, also check that an unchanged second build stays incremental.\n3. Report timing as the median of at least three runs; if you could not run the build, say \"not validated\".\n\n## Output\n\nFor on-target requests, keep the answer proportional to the evidence: a compact findings table with at least one row, a short explanation of the decisive computation or preservation constraint, and a standalone, unformatted `Verdict:` line. Do not bold the line or append it to a paragraph. Use `unknown` for unavailable timing or critical-path evidence; distinguish estimated aggregate task time from measured wall-clock savings. If the contract requires every execution, report zero avoidable time even when task durations are unknown.\n\n| Work | Calls | Expected | Avoidable ms | Cause | Fix | On critical path? |\n|---|---|---|---|---|---|---|\n\nAfter verification: `Verdict: removed N repeated executions, measured wall-clock saving X s`.\n\nWithout verification: `Verdict: proposed removal of N repeated executions; estimated task-time saving X s; wall-clock not validated`.\n\nWhen no change is worthwhile: `Verdict: no repeated work worth changing`.\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---|---|\n| Treating `Csc` or copy-local counts as waste | Compare `Csc` with projects times TFMs, and copies with required files and targets; do not assume both have the same expected count |\n| Guarding with `Exists(file)` or a flag property | Move the work out of the per-project path |\n| Assuming parent-local properties are inherited by child builds | Forward the shared value explicitly or load it in each child before the fallback; otherwise the fallback repeats in those children. Existing global properties are already inherited unless removed. |\n| Claiming a saving from total task time | Check actual overlap and the critical path; do not divide sequential work by unrelated busy nodes |\n| Merging per-item `Exec` and losing incrementality | Keep `Inputs` and `Outputs` on the target |\n",{"name":5,"license":15,"description":7},"main","367e97f05fa5a6d7068734d340cfa415690d8a33","catalog\u002FTools\u002FOfficial-DotNet-MSBuild\u002Fskills\u002Ffind-repeated-work-within-one-build",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-12 19:59:36",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add managedcode\u002Fdotnet-skills --skill find-repeated-work-within-one-build",{"tool":62,"command":63},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill find-repeated-work-within-one-build",{"tool":65,"command":66},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill find-repeated-work-within-one-build","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FOfficial-DotNet-MSBuild\u002Fskills\u002Ffind-repeated-work-within-one-build\u002FSKILL.md",true,[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"manifest.json","REFERENCE","参考文档",137,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FOfficial-DotNet-MSBuild\u002Fskills\u002Ffind-repeated-work-within-one-build\u002Fmanifest.json",[77,112,135,165,175,201],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":93,"publishedAt":41},"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",[83,88],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[94,95,96,33,97,98,99,100,101,102,103,104,105,106,107,108,109,31,110,111],"xtwitter scraper","browser automation","workflows","code","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","files","social","modeling","webhook",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":124,"publishedAt":41},"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",[118,121],{"categoryNo":119,"categoryName":120,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":122,"categoryName":123,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000036","内容创作者",[114,125,126,96,127,33,100,128,129,130,105,131,106,108,34,132,133,32,31,134],"writing","performance","tasks","data","parsing","parser","context","writer","options","high-performance",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":41},"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",[],[142,143,144,145,146,147,148,149,150,38,151,152,153,154,155,156,157,158,159,160,28,161,162,163,164],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","syntax","guide","use","language","three","compute","post","processing","with","renderer","materials","wgsl","effects","when",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":41},"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",[],[167,153,108,172,173,28,174],"semantic","razor","inspection",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":41},"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",[],[182,183,184,185,125,186,187,188,189,190,191,153,36,192,193,194,34,195,196,197,198,28,199,200,164],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":209,"publishedAt":41},"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",[207,208],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[101,210,211,212,33,213,149,182,153,193,194,34,214,215,216,217,198,28,218],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]