[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M75G2SCJPWZAAXGVJB05F2AC":3,"skill-same:01M75G2SCJPWZAAXGVJB05F2AC":46},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":6,"updatedAt":31,"install":32,"resources":45},"01M75G2SCJPWZAAXGVJB05F2AC","build-perf-diagnostics",null,"Diagnose MSBuild bottlenecks from binlog timelines and Target\u002FTask Performance Summaries after baseline measurements. USE FOR: unknown build slowness, RAR >5s, analyzers >30% of Csc, a target >50% of build, node utilization below 80%, excessive Copy, restore overhead. DO NOT USE FOR: within-build duplicates (find-repeated-work-within-one-build), known repeated restores (eliminate-redundant-restores), initial baselines (build-perf-baseline), incremental rebuilds (incremental-build), parallelism tuning (build-parallelism), non-MSBuild builds.","stanfish06\u002Fskillquarium","stanfish06","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F93099613?v=4","01M75F1CK4ZW109ZK3T26VN52F","Zhiyuan","01M75F1CM53VH6F79DZ8GXKKES",12,"MIT","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fbuild-perf-diagnostics\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: build-perf-diagnostics\ndescription: \"Diagnose MSBuild bottlenecks from binlog timelines and Target\u002FTask Performance Summaries after baseline measurements. USE FOR: unknown build slowness, RAR >5s, analyzers >30% of Csc, a target >50% of build, node utilization below 80%, excessive Copy, restore overhead. DO NOT USE FOR: within-build duplicates (find-repeated-work-within-one-build), known repeated restores (eliminate-redundant-restores), initial baselines (build-perf-baseline), incremental rebuilds (incremental-build), parallelism tuning (build-parallelism), non-MSBuild builds.\"\nlicense: MIT\n---\n\n## Performance Analysis Methodology\n\n1. **Generate a binlog**: `dotnet build \u002Fbl:{} -m`\n2. Use the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace) which is bundled with this plugin\n\nIf the server cannot connect, use `troubleshoot-binlog-mcp` when startup repair is\nwanted. If repair is blocked, declined, or unnecessary, use the replay flow below.\n\n### Alternate flow when MCP is unavailable: binlog replay to text logs\n\n1. **Generate a binlog**: `dotnet build \u002Fbl:{} -m`\n2. **Replay to diagnostic log with performance summary**:\n   ```bash\n   dotnet msbuild build.binlog -noconlog -fl \"-flp:v=diag;logfile=full.log;performancesummary\"\n   ```\n3. **Read the performance summary** (at the end of `full.log`):\n   ```bash\n   grep \"Target Performance Summary\\|Task Performance Summary\" -A 50 full.log\n   ```\n4. **Find expensive targets and tasks**: The PerformanceSummary section lists all targets\u002Ftasks sorted by cumulative time\n5. **Check for node utilization**: grep for scheduling and node messages\n   ```bash\n   grep -i \"node.*assigned\\|building with\\|scheduler\" full.log | head -30\n   ```\n6. **Check analyzers**: grep for analyzer timing\n   ```bash\n   grep -i \"analyzer.*elapsed\\|Total analyzer execution time\\|CompilerAnalyzerDriver\" full.log\n   ```\n\n## Key Metrics and Thresholds\n\n- **Build duration**: what's \"normal\" — small project \u003C10s, medium \u003C60s, large \u003C5min\n- **Node utilization**: ideal is >80% active time across nodes. Low utilization = serialization bottleneck\n- **Single target domination**: if one target is >50% of build time, investigate\n- **Analyzer time vs compile time**: analyzers should be \u003C30% of Csc task time. If higher, consider removing expensive analyzers\n- **RAR time**: ResolveAssemblyReference >5s is concerning. >15s is pathological\n\n## Common Bottlenecks\n\n### 1. ResolveAssemblyReference (RAR) Slowness\n\n- **Symptoms**: RAR taking >5s per project\n- **Root causes**: too many assembly references, network-based reference paths, large assembly search paths\n- **Fixes**: reduce reference count, use `\u003CDesignTimeBuild>false\u003C\u002FDesignTimeBuild>` for RAR-heavy analysis, set `\u003CResolveAssemblyReferencesSilent>true\u003C\u002FResolveAssemblyReferencesSilent>` for diagnostic\n- **Advanced**: `\u003CDesignTimeBuild>` and `\u003CResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>`\n- **Key insight**: RAR runs unconditionally even on incremental builds because users may have installed targeting packs or GACed assemblies (see dotnet\u002Fmsbuild#2015). With .NET Core micro-assemblies, the reference count is often very high.\n- **Reduce transitive references**: Set `\u003CDisableTransitiveProjectReferences>true\u003C\u002FDisableTransitiveProjectReferences>` to avoid pulling in the full transitive closure (note: projects may need to add direct references for any types they consume). Use `ReferenceOutputAssembly=\"false\"` on ProjectReferences that are only needed at build time (not API surface). Trim unused PackageReferences.\n\n### 2. Roslyn Analyzers and Source Generators\n\n- **Symptoms**: Csc task takes much longer than expected for file count (>2× clean compile time)\n- **Diagnosis**: Check the Task Performance Summary in the replayed log for Csc task time; grep for analyzer timing messages; compare Csc duration with and without analyzers (`\u002Fp:RunAnalyzers=false`)\n- **Fixes**:\n  - Conditionally disable in dev: `\u003CRunAnalyzers Condition=\"'$(ContinuousIntegrationBuild)' != 'true'\">false\u003C\u002FRunAnalyzers>`\n  - Per-configuration: `\u003CRunAnalyzers Condition=\"'$(Configuration)' == 'Debug'\">false\u003C\u002FRunAnalyzers>`\n  - Code-style only: `\u003CEnforceCodeStyleInBuild Condition=\"'$(ContinuousIntegrationBuild)' == 'true'\">true\u003C\u002FEnforceCodeStyleInBuild>`\n  - Remove genuinely redundant analyzers from inner loop\n  - Severity config in .editorconfig for less critical rules\n- **Key principle**: Preserve analyzer enforcement in CI. Never just \"remove\" analyzers — configure them conditionally.\n- **GlobalPackageReference**: Analyzers added via `GlobalPackageReference` in `Directory.Packages.props` apply to ALL projects. Consider if test projects need the same analyzer set as production code.\n- **EnforceCodeStyleInBuild**: When set to `true` in `Directory.Build.props`, forces code-style analysis on every build. Should be conditional on CI environment (`ContinuousIntegrationBuild`) to avoid slowing dev inner loop.\n\n### 3. Serialization Bottlenecks (Single-threaded targets)\n\n- **Symptoms**: Performance summary shows most build time concentrated in a single project; diagnostic log shows idle nodes while one works\n- **Common culprits**: targets without proper dependency declaration, single project on critical path\n- **Fixes**: split large projects, optimize the critical path project, ensure proper `BuildInParallel`\n\n### 4. Excessive File I\u002FO (Copy tasks)\n\n- **Symptoms**: Copy task shows high aggregate time\n- **Root causes**: copying thousands of files, copying across network drives, Copy task unintentionally running once per item (per-file) instead of as a single batch (see dotnet\u002Fmsbuild#12884)\n- **Fixes**: use hardlinks (`\u003CCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>true\u003C\u002FCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>`), reduce CopyToOutputDirectory items, use `\u003CUseCommonOutputDirectory>true\u003C\u002FUseCommonOutputDirectory>` when appropriate, set `\u003CSkipCopyUnchangedFiles>true\u003C\u002FSkipCopyUnchangedFiles>`, consider `--artifacts-path` (.NET 8+) for centralized output layout\n- **Dev Drive**: On Windows, switching to a Dev Drive (ReFS with copy-on-write and reduced Defender scans) can significantly reduce file I\u002FO overhead for Copy-heavy builds. Recommend for both dev machines and self-hosted CI agents.\n\n### 5. Evaluation Overhead\n\n- **Symptoms**: build starts slow before any compilation\n- **Root causes**: complex Directory.Build.props, wildcard globs scanning large directories, NuGetSdkResolver overhead (adds 180-400ms per project evaluation even when restored — see dotnet\u002Fmsbuild#4025)\n- **Fixes**: reduce Directory.Build.props complexity, use `\u003CEnableDefaultItems>false\u003C\u002FEnableDefaultItems>` for legacy projects with explicit file lists, avoid NuGet-based SDK resolvers if possible\n- See: `eval-performance` skill for detailed guidance\n\n### 6. NuGet Restore in Build\n\n- **Symptoms**: restore runs every build even when unnecessary\n- **Fixes**:\n  - Separate restore from build: `dotnet restore` then `dotnet build --no-restore`\n  - Enable static graph evaluation: `\u003CRestoreUseStaticGraphEvaluation>true\u003C\u002FRestoreUseStaticGraphEvaluation>` in Directory.Build.props — can save significant time in large builds (results are workload-dependent)\n- See: `eliminate-redundant-restores` skill when several pipeline or script steps each restore, or before adding `--no-restore` (it fails with NETSDK1004\u002FNETSDK1047 when no earlier restore covers the step)\n\n### 7. Large Project Count and Graph Shape\n\n- **Symptoms**: many small projects, each takes minimal time but overhead adds up; deep dependency chains serialize the build\n- **Consider**: project consolidation, or use `\u002Fgraph` mode for better scheduling\n- **Graph shape matters**: a wide dependency graph (few levels, many parallel branches) builds faster than a deep one (many levels, serialized). Refactoring from deep to wide can yield significant improvements in both clean and incremental build times.\n- **Actions**: look for unnecessary project dependencies, consider splitting a bottleneck project into two, or merging small leaf projects\n\n## Using Binlog Replay for Performance Analysis\n\nStep-by-step workflow using text log replay:\n\n1. **Replay with performance summary**:\n   ```bash\n   dotnet msbuild build.binlog -noconlog -fl \"-flp:v=diag;logfile=full.log;performancesummary\"\n   ```\n2. **Read target\u002Ftask performance summaries** (at the end of `full.log`):\n   ```bash\n   grep \"Target Performance Summary\\|Task Performance Summary\" -A 50 full.log\n   ```\n   This shows all targets and tasks sorted by cumulative time — equivalent to finding expensive targets\u002Ftasks.\n3. **Find per-project build times**:\n   ```bash\n   grep \"done building project\\|Project Performance Summary\" full.log\n   ```\n4. **Check parallelism** (multi-node scheduling):\n   ```bash\n   grep -i \"node.*assigned\\|RequiresLeadingNewline\\|Building with\" full.log | head -30\n   ```\n5. **Check analyzer overhead**:\n   ```bash\n   grep -i \"Total analyzer execution time\\|analyzer.*elapsed\\|CompilerAnalyzerDriver\" full.log\n   ```\n6. **Drill into a specific slow target**:\n   ```bash\n   grep 'Target \"CoreCompile\"\\|Target \"ResolveAssemblyReferences\"' full.log\n   ```\n\n## Quick Wins Checklist\n\n- [ ] Use `\u002Fmaxcpucount` (or `-m`) for parallel builds\n- [ ] Separate restore from build (`dotnet restore` then `dotnet build --no-restore`)\n- [ ] Enable static graph restore (`\u003CRestoreUseStaticGraphEvaluation>true\u003C\u002FRestoreUseStaticGraphEvaluation>`)\n- [ ] Enable hardlinks for Copy (`\u003CCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>true\u003C\u002FCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>`)\n- [ ] Disable analyzers conditionally in dev inner loop: `\u003CRunAnalyzers Condition=\"'$(ContinuousIntegrationBuild)' != 'true'\">false\u003C\u002FRunAnalyzers>`\n- [ ] Enable reference assemblies (`\u003CProduceReferenceAssembly>true\u003C\u002FProduceReferenceAssembly>`)\n- [ ] Check for broken incremental builds (see `incremental-build` skill)\n- [ ] Check for bin\u002Fobj clashes (see `check-bin-obj-clash` skill)\n- [ ] Use graph build (`\u002Fgraph`) for multi-project solutions\n- [ ] Use `--artifacts-path` (.NET 8+) for centralized output layout\n- [ ] Enable Dev Drive (ReFS) on Windows dev machines and self-hosted CI\n\n## Impact Categorization\n\nWhen reporting findings, categorize by impact to help prioritize fixes:\n\n- 🔴 **HIGH IMPACT** (do first): Items consuming >10% of total build time, or a single target >50% of build time\n- 🟡 **MEDIUM IMPACT**: Items consuming 2-10% of build time\n- 🟢 **QUICK WINS**: Easy changes with modest impact (e.g., property flags in Directory.Build.props)\n","## Performance Analysis Methodology\n\n1. **Generate a binlog**: `dotnet build \u002Fbl:{} -m`\n2. Use the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace) which is bundled with this plugin\n\nIf the server cannot connect, use `troubleshoot-binlog-mcp` when startup repair is\nwanted. If repair is blocked, declined, or unnecessary, use the replay flow below.\n\n### Alternate flow when MCP is unavailable: binlog replay to text logs\n\n1. **Generate a binlog**: `dotnet build \u002Fbl:{} -m`\n2. **Replay to diagnostic log with performance summary**:\n   ```bash\n   dotnet msbuild build.binlog -noconlog -fl \"-flp:v=diag;logfile=full.log;performancesummary\"\n   ```\n3. **Read the performance summary** (at the end of `full.log`):\n   ```bash\n   grep \"Target Performance Summary\\|Task Performance Summary\" -A 50 full.log\n   ```\n4. **Find expensive targets and tasks**: The PerformanceSummary section lists all targets\u002Ftasks sorted by cumulative time\n5. **Check for node utilization**: grep for scheduling and node messages\n   ```bash\n   grep -i \"node.*assigned\\|building with\\|scheduler\" full.log | head -30\n   ```\n6. **Check analyzers**: grep for analyzer timing\n   ```bash\n   grep -i \"analyzer.*elapsed\\|Total analyzer execution time\\|CompilerAnalyzerDriver\" full.log\n   ```\n\n## Key Metrics and Thresholds\n\n- **Build duration**: what's \"normal\" — small project \u003C10s, medium \u003C60s, large \u003C5min\n- **Node utilization**: ideal is >80% active time across nodes. Low utilization = serialization bottleneck\n- **Single target domination**: if one target is >50% of build time, investigate\n- **Analyzer time vs compile time**: analyzers should be \u003C30% of Csc task time. If higher, consider removing expensive analyzers\n- **RAR time**: ResolveAssemblyReference >5s is concerning. >15s is pathological\n\n## Common Bottlenecks\n\n### 1. ResolveAssemblyReference (RAR) Slowness\n\n- **Symptoms**: RAR taking >5s per project\n- **Root causes**: too many assembly references, network-based reference paths, large assembly search paths\n- **Fixes**: reduce reference count, use `\u003CDesignTimeBuild>false\u003C\u002FDesignTimeBuild>` for RAR-heavy analysis, set `\u003CResolveAssemblyReferencesSilent>true\u003C\u002FResolveAssemblyReferencesSilent>` for diagnostic\n- **Advanced**: `\u003CDesignTimeBuild>` and `\u003CResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>`\n- **Key insight**: RAR runs unconditionally even on incremental builds because users may have installed targeting packs or GACed assemblies (see dotnet\u002Fmsbuild#2015). With .NET Core micro-assemblies, the reference count is often very high.\n- **Reduce transitive references**: Set `\u003CDisableTransitiveProjectReferences>true\u003C\u002FDisableTransitiveProjectReferences>` to avoid pulling in the full transitive closure (note: projects may need to add direct references for any types they consume). Use `ReferenceOutputAssembly=\"false\"` on ProjectReferences that are only needed at build time (not API surface). Trim unused PackageReferences.\n\n### 2. Roslyn Analyzers and Source Generators\n\n- **Symptoms**: Csc task takes much longer than expected for file count (>2× clean compile time)\n- **Diagnosis**: Check the Task Performance Summary in the replayed log for Csc task time; grep for analyzer timing messages; compare Csc duration with and without analyzers (`\u002Fp:RunAnalyzers=false`)\n- **Fixes**:\n  - Conditionally disable in dev: `\u003CRunAnalyzers Condition=\"'$(ContinuousIntegrationBuild)' != 'true'\">false\u003C\u002FRunAnalyzers>`\n  - Per-configuration: `\u003CRunAnalyzers Condition=\"'$(Configuration)' == 'Debug'\">false\u003C\u002FRunAnalyzers>`\n  - Code-style only: `\u003CEnforceCodeStyleInBuild Condition=\"'$(ContinuousIntegrationBuild)' == 'true'\">true\u003C\u002FEnforceCodeStyleInBuild>`\n  - Remove genuinely redundant analyzers from inner loop\n  - Severity config in .editorconfig for less critical rules\n- **Key principle**: Preserve analyzer enforcement in CI. Never just \"remove\" analyzers — configure them conditionally.\n- **GlobalPackageReference**: Analyzers added via `GlobalPackageReference` in `Directory.Packages.props` apply to ALL projects. Consider if test projects need the same analyzer set as production code.\n- **EnforceCodeStyleInBuild**: When set to `true` in `Directory.Build.props`, forces code-style analysis on every build. Should be conditional on CI environment (`ContinuousIntegrationBuild`) to avoid slowing dev inner loop.\n\n### 3. Serialization Bottlenecks (Single-threaded targets)\n\n- **Symptoms**: Performance summary shows most build time concentrated in a single project; diagnostic log shows idle nodes while one works\n- **Common culprits**: targets without proper dependency declaration, single project on critical path\n- **Fixes**: split large projects, optimize the critical path project, ensure proper `BuildInParallel`\n\n### 4. Excessive File I\u002FO (Copy tasks)\n\n- **Symptoms**: Copy task shows high aggregate time\n- **Root causes**: copying thousands of files, copying across network drives, Copy task unintentionally running once per item (per-file) instead of as a single batch (see dotnet\u002Fmsbuild#12884)\n- **Fixes**: use hardlinks (`\u003CCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>true\u003C\u002FCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>`), reduce CopyToOutputDirectory items, use `\u003CUseCommonOutputDirectory>true\u003C\u002FUseCommonOutputDirectory>` when appropriate, set `\u003CSkipCopyUnchangedFiles>true\u003C\u002FSkipCopyUnchangedFiles>`, consider `--artifacts-path` (.NET 8+) for centralized output layout\n- **Dev Drive**: On Windows, switching to a Dev Drive (ReFS with copy-on-write and reduced Defender scans) can significantly reduce file I\u002FO overhead for Copy-heavy builds. Recommend for both dev machines and self-hosted CI agents.\n\n### 5. Evaluation Overhead\n\n- **Symptoms**: build starts slow before any compilation\n- **Root causes**: complex Directory.Build.props, wildcard globs scanning large directories, NuGetSdkResolver overhead (adds 180-400ms per project evaluation even when restored — see dotnet\u002Fmsbuild#4025)\n- **Fixes**: reduce Directory.Build.props complexity, use `\u003CEnableDefaultItems>false\u003C\u002FEnableDefaultItems>` for legacy projects with explicit file lists, avoid NuGet-based SDK resolvers if possible\n- See: `eval-performance` skill for detailed guidance\n\n### 6. NuGet Restore in Build\n\n- **Symptoms**: restore runs every build even when unnecessary\n- **Fixes**:\n  - Separate restore from build: `dotnet restore` then `dotnet build --no-restore`\n  - Enable static graph evaluation: `\u003CRestoreUseStaticGraphEvaluation>true\u003C\u002FRestoreUseStaticGraphEvaluation>` in Directory.Build.props — can save significant time in large builds (results are workload-dependent)\n- See: `eliminate-redundant-restores` skill when several pipeline or script steps each restore, or before adding `--no-restore` (it fails with NETSDK1004\u002FNETSDK1047 when no earlier restore covers the step)\n\n### 7. Large Project Count and Graph Shape\n\n- **Symptoms**: many small projects, each takes minimal time but overhead adds up; deep dependency chains serialize the build\n- **Consider**: project consolidation, or use `\u002Fgraph` mode for better scheduling\n- **Graph shape matters**: a wide dependency graph (few levels, many parallel branches) builds faster than a deep one (many levels, serialized). Refactoring from deep to wide can yield significant improvements in both clean and incremental build times.\n- **Actions**: look for unnecessary project dependencies, consider splitting a bottleneck project into two, or merging small leaf projects\n\n## Using Binlog Replay for Performance Analysis\n\nStep-by-step workflow using text log replay:\n\n1. **Replay with performance summary**:\n   ```bash\n   dotnet msbuild build.binlog -noconlog -fl \"-flp:v=diag;logfile=full.log;performancesummary\"\n   ```\n2. **Read target\u002Ftask performance summaries** (at the end of `full.log`):\n   ```bash\n   grep \"Target Performance Summary\\|Task Performance Summary\" -A 50 full.log\n   ```\n   This shows all targets and tasks sorted by cumulative time — equivalent to finding expensive targets\u002Ftasks.\n3. **Find per-project build times**:\n   ```bash\n   grep \"done building project\\|Project Performance Summary\" full.log\n   ```\n4. **Check parallelism** (multi-node scheduling):\n   ```bash\n   grep -i \"node.*assigned\\|RequiresLeadingNewline\\|Building with\" full.log | head -30\n   ```\n5. **Check analyzer overhead**:\n   ```bash\n   grep -i \"Total analyzer execution time\\|analyzer.*elapsed\\|CompilerAnalyzerDriver\" full.log\n   ```\n6. **Drill into a specific slow target**:\n   ```bash\n   grep 'Target \"CoreCompile\"\\|Target \"ResolveAssemblyReferences\"' full.log\n   ```\n\n## Quick Wins Checklist\n\n- [ ] Use `\u002Fmaxcpucount` (or `-m`) for parallel builds\n- [ ] Separate restore from build (`dotnet restore` then `dotnet build --no-restore`)\n- [ ] Enable static graph restore (`\u003CRestoreUseStaticGraphEvaluation>true\u003C\u002FRestoreUseStaticGraphEvaluation>`)\n- [ ] Enable hardlinks for Copy (`\u003CCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>true\u003C\u002FCreateHardLinksForCopyFilesToOutputDirectoryIfPossible>`)\n- [ ] Disable analyzers conditionally in dev inner loop: `\u003CRunAnalyzers Condition=\"'$(ContinuousIntegrationBuild)' != 'true'\">false\u003C\u002FRunAnalyzers>`\n- [ ] Enable reference assemblies (`\u003CProduceReferenceAssembly>true\u003C\u002FProduceReferenceAssembly>`)\n- [ ] Check for broken incremental builds (see `incremental-build` skill)\n- [ ] Check for bin\u002Fobj clashes (see `check-bin-obj-clash` skill)\n- [ ] Use graph build (`\u002Fgraph`) for multi-project solutions\n- [ ] Use `--artifacts-path` (.NET 8+) for centralized output layout\n- [ ] Enable Dev Drive (ReFS) on Windows dev machines and self-hosted CI\n\n## Impact Categorization\n\nWhen reporting findings, categorize by impact to help prioritize fixes:\n\n- 🔴 **HIGH IMPACT** (do first): Items consuming >10% of total build time, or a single target >50% of build time\n- 🟡 **MEDIUM IMPACT**: Items consuming 2-10% of build time\n- 🟢 **QUICK WINS**: Easy changes with modest impact (e.g., property flags in Directory.Build.props)\n",{"name":5,"license":15,"description":7},"master","49e49abf2f670d429e0b7e2c0349739c3fdd5cbe","skills\u002Fbuild-perf-diagnostics",5,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium","https:\u002F\u002Fgithub.com\u002Fstanfish06","https:\u002F\u002Fwww.stanfish.dev\u002F","2026-11-14 21:31:37",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add stanfish06\u002Fskillquarium --skill build-perf-diagnostics",{"tool":38,"command":39},"bunx","bunx skills add stanfish06\u002Fskillquarium --skill build-perf-diagnostics",{"tool":41,"command":42},"pnpm","pnpm dlx skills add stanfish06\u002Fskillquarium --skill build-perf-diagnostics","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fbuild-perf-diagnostics\u002FSKILL.md",true,[],[47,54,63,70,77,84],{"skillNo":48,"name":49,"nameZh":6,"description":50,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":51,"categories":52,"keywords":53,"publishedAt":19},"01M76ZJTRVA456GD7K8Y3EP82H","zarr-python","Stores and queries chunked N-D scientific arrays with Zarr-Python 3, including codecs, sharding, S3\u002FGCS storage, and NumPy\u002FDask\u002FXarray integration. Use for array layout, bounded I\u002FO, format migration, or scientific metadata preservation.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fzarr-python\u002FSKILL.md",[],[],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":58,"licenseFileUrl":59,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M76ZJQZ15Q1HKC5V85NHE325","yeet","Publish local changes to GitHub by confirming scope, committing intentionally, pushing the branch, and opening a draft PR through the GitHub app from this plugin, with `gh` used only as a fallback where connector coverage is insufficient.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fyeet\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fyeet\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":58,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M76ZJ8ASZ4QYQ70Y6SBA4Z4S","xarray","N-dimensional labeled arrays and datasets in Python. Built on top of NumPy and Dask. It introduces labels in the form of dimensions, coordinates, and attributes on top of raw NumPy-like arrays, making data analysis in physical sciences more intuitive and less error-prone. Use for working with multi-dimensional scientific data, NetCDF\u002FGRIB\u002FZarr files, climate\u002Fweather\u002Foceanographic datasets, remote sensing, geospatial imaging, large out-of-memory datasets with Dask, and labeled array operations.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fxarray\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M76ZHFBXD6VXPQ02VCEG202B","writing-mstest-tests","Use when asked to fix, rewrite, update, improve, modernize, show corrected code for, or explain existing MSTest tests or MSTest-specific configuration. Use for \"review\" when corrected code or edits are wanted, even for one pasted assertion or passing tests with bad failure output. Covers expected\u002Factual labels; generic Boolean, collection, string, numeric, null, identity, exception, hard-cast, and object[] checks; TestContext\u002Flifecycle; timeout\u002Fcancellation; OS\u002FCI conditions, retry, cleanup, parallelization, MSTest.Sdk project setup, and MSTESTxxxx. Honor the installed MSTest version. DO NOT USE to design new test cases (code-testing), perform report-only audits, create project files rather than explain MSTest setup, run tests, migrate frameworks, or handle non-MSTest\u002Fnon-.NET code.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwriting-mstest-tests\u002FSKILL.md",[],[],{"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":83,"publishedAt":19},"01M76ZDFDF4N88RH6HSYGS7GP2","wgs-prs","End-to-end WGS to polygenic risk score pipeline. Takes paired-end FASTQ files (or a pre-existing VCF) through nf-core\u002Fsarek for variant calling, applies VCF QC (normalisation, hard filtering, Ti\u002FTv and Het\u002FHom checks), then computes polygenic risk scores via the PGS Catalog. Fills the FASTQ to VCF gap upstream of the gwas-prs skill.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwgs-prs\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":58,"licenseFileUrl":88,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M76ZCC1SC68J42QK4MDC8RCG","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[],[]]