[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699CJ2JT5FNWD7FSDK1NRHN":3,"skill-same:01M699CJ2JT5FNWD7FSDK1NRHN":67},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M699CJ2JT5FNWD7FSDK1NRHN","build-parallelism",null,"Analyze MSBuild scheduling across at least two distinct projects in a solution\u002Ffilter\u002FBuild.proj. USE FOR: measured idle workers, -m not scaling, serial ProjectReference critical paths, graph builds, MSBuild Projects-list scheduling. DO NOT USE FOR: duplicate executions or invariant-generation races (find-repeated-work-within-one-build), non-MSBuild systems.","microsoft\u002Ftestfx","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699C71CJ91B5WZ3AXG3GG2M",1059,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbuild-parallelism\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"build","build parallelism","msbuild","duplicate","scheduling","workers","use","for","do","graph","list","paths","at","work","analyze","across","filter","critical","scaling","projects","2026-11-10 10:12:30",false,"---\nname: build-parallelism\ndescription: \"Analyze MSBuild scheduling across at least two distinct projects in a solution\u002Ffilter\u002FBuild.proj. USE FOR: measured idle workers, -m not scaling, serial ProjectReference critical paths, graph builds, MSBuild Projects-list scheduling. DO NOT USE FOR: duplicate executions or invariant-generation races (find-repeated-work-within-one-build), non-MSBuild systems.\"\nlicense: MIT\n---\n\n## Diagnose a slow parallel build (start here)\n\nWork this checklist in order — it targets the usual root cause (a serial\ndependency chain that no number of cores can parallelize):\n\n1. **Check how many worker nodes actually built the solution.** Capture a\n   binlog with `dotnet build \u002Fbl:{}` (PowerShell: `dotnet build '-bl:{}'`) and\n   inspect the node timeline to see whether more than one node ran. Every\n   `dotnet` CLI command built on the SDK's MSBuild-forwarding path (`build`,\n   `msbuild`, `test`, `pack`, `publish`, etc.) enables `\u002Fmaxcpucount` (multiple\n   nodes) by default; `-m:1` forces a single node. A direct `MSBuild.exe`\n   invocation is sequential by default, so pass `-m` explicitly to enable\n   parallel worker nodes there.\n2. **Find the critical path.** From the binlog, read per-project timings and the\n   node timeline. If total build time ≈ the sum of the projects on one\n   dependency chain, that chain — not CPU count — is the bottleneck.\n3. **Name the chain explicitly**, e.g. `Core → Api → Web → Tests`. A long serial\n   chain stays serial no matter how large `-m` is, because each project waits on\n   its predecessor.\n4. **Look for unnecessary `ProjectReference` edges** that lengthen the chain — a\n   reference that only needs build order (not the output assembly), or one that\n   could be a `PackageReference`, forces serialization it doesn't need.\n5. **Recommend flattening**: break false dependencies so independent projects\n   build concurrently, and consider `\u002Fgraph` for better scheduling.\n\n## MSBuild Parallelism Model\n\n- `\u002Fmaxcpucount` (or `-m`): number of worker nodes (processes)\n- Every `dotnet` CLI command (`build`, `msbuild`, `test`, `pack`, `publish`,\n  etc.) passes `\u002Fmaxcpucount` by default via the SDK's shared MSBuild-forwarding\n  path; `-m:1` overrides it with one node\n- A direct `MSBuild.exe` invocation is sequential by default and requires an\n  explicit `-m`\n- Recommended: `-m` without a number = use all logical processors\n- Each node builds one project at a time\n- Projects are scheduled based on dependency graph\n\n## Project Dependency Graph\n\n- MSBuild builds projects in dependency order (topological sort)\n- Critical path: longest chain of dependent projects determines minimum build time\n- Bottleneck: if project A depends on B, C, D and B takes 60s while C and D take 5s, B is the bottleneck\n- Diagnosis: replay binlog to diagnostic log with `performancesummary` and check Project Performance Summary — shows per-project time; grep for `node.*assigned` to check scheduling\n- Wide graphs (many independent projects) parallelize well; deep graphs (long chains) don't\n\n## Graph Build Mode (`\u002Fgraph`)\n\n- `dotnet build \u002Fgraph` or `msbuild \u002Fgraph`\n- What it changes: MSBuild constructs the full project dependency graph BEFORE building\n- Benefits: better scheduling, avoids redundant evaluations, enables isolated builds\n- Limitations: all projects must use `\u003CProjectReference>` (no programmatic MSBuild task references)\n- When to use: large solutions with many projects, CI builds\n- When NOT to use: projects that dynamically discover references at build time\n\n## Optimizing Project References\n\n- Reduce a `\u003CProjectReference>` only after proving it is unnecessary; a slow but\n  valid dependency must stay in the graph\n- Use `\u003CProjectReference ... SkipGetTargetFrameworkProperties=\"true\">` to avoid extra evaluations\n- `\u003CProjectReference ... ReferenceOutputAssembly=\"false\">` for build-order-only dependencies\n- Consider if a ProjectReference should be a PackageReference instead (pre-built NuGet)\n- Use `solution filters` (`.slnf`) to build subsets of the solution\n\n## BuildInParallel\n\n- `\u003CMSBuild Projects=\"@(ProjectsToBuild)\" BuildInParallel=\"true\" \u002F>` in custom targets\n- Without `BuildInParallel=\"true\"`, MSBuild task batches projects sequentially\n- Ensure `\u002Fmaxcpucount` > 1 for this to have effect\n\n## Multi-threaded MSBuild Tasks\n\n- Individual tasks can run multi-threaded within a single project build\n- Tasks implementing `IMultiThreadableTask` can run on multiple threads\n- Tasks must declare thread-safety via `[MSBuildMultiThreadableTask]`\n\n## Analyzing Parallelism with Binlog\n\n### Primary: binlog MCP (preferred)\n\nUse the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace):\n\n1. Use expensive_projects tool → find the slowest projects and compare individual vs total build time\n2. Use expensive_targets tool → find bottleneck targets\n3. Use project_target_times tool → drill into a specific project's target-level timing\n4. Ideal: build time should be much less than sum of project times (parallelism)\n5. If build time ≈ sum of project times: too many serial dependencies, or one slow project blocking others\n\n### Fallback: text-log replay (when MCP is unavailable)\n\nStep-by-step:\n\n1. Replay the binlog: `dotnet msbuild build.binlog -noconlog -fl \"-flp:v=diag;logfile=full.log;performancesummary\"`\n2. Check Project Performance Summary at the end of `full.log`\n3. Ideal: build time should be much less than sum of project times (parallelism)\n4. If build time ≈ sum of project times: too many serial dependencies, or one slow project blocking others\n5. `grep 'Target Performance Summary' -A 30 full.log` → find the bottleneck targets\n6. Consider splitting large projects or optimizing the critical path\n\n## CI\u002FCD Parallelism Tips\n\n- Use `-m` in CI (many CI runners have multiple cores)\n- Consider splitting solution into build stages for extreme parallelism\n- Use build caching (NuGet lock files, deterministic builds) to avoid rebuilding unchanged projects\n- `dotnet build \u002Fgraph` works well with structured CI pipelines\n","## Diagnose a slow parallel build (start here)\n\nWork this checklist in order — it targets the usual root cause (a serial\ndependency chain that no number of cores can parallelize):\n\n1. **Check how many worker nodes actually built the solution.** Capture a\n   binlog with `dotnet build \u002Fbl:{}` (PowerShell: `dotnet build '-bl:{}'`) and\n   inspect the node timeline to see whether more than one node ran. Every\n   `dotnet` CLI command built on the SDK's MSBuild-forwarding path (`build`,\n   `msbuild`, `test`, `pack`, `publish`, etc.) enables `\u002Fmaxcpucount` (multiple\n   nodes) by default; `-m:1` forces a single node. A direct `MSBuild.exe`\n   invocation is sequential by default, so pass `-m` explicitly to enable\n   parallel worker nodes there.\n2. **Find the critical path.** From the binlog, read per-project timings and the\n   node timeline. If total build time ≈ the sum of the projects on one\n   dependency chain, that chain — not CPU count — is the bottleneck.\n3. **Name the chain explicitly**, e.g. `Core → Api → Web → Tests`. A long serial\n   chain stays serial no matter how large `-m` is, because each project waits on\n   its predecessor.\n4. **Look for unnecessary `ProjectReference` edges** that lengthen the chain — a\n   reference that only needs build order (not the output assembly), or one that\n   could be a `PackageReference`, forces serialization it doesn't need.\n5. **Recommend flattening**: break false dependencies so independent projects\n   build concurrently, and consider `\u002Fgraph` for better scheduling.\n\n## MSBuild Parallelism Model\n\n- `\u002Fmaxcpucount` (or `-m`): number of worker nodes (processes)\n- Every `dotnet` CLI command (`build`, `msbuild`, `test`, `pack`, `publish`,\n  etc.) passes `\u002Fmaxcpucount` by default via the SDK's shared MSBuild-forwarding\n  path; `-m:1` overrides it with one node\n- A direct `MSBuild.exe` invocation is sequential by default and requires an\n  explicit `-m`\n- Recommended: `-m` without a number = use all logical processors\n- Each node builds one project at a time\n- Projects are scheduled based on dependency graph\n\n## Project Dependency Graph\n\n- MSBuild builds projects in dependency order (topological sort)\n- Critical path: longest chain of dependent projects determines minimum build time\n- Bottleneck: if project A depends on B, C, D and B takes 60s while C and D take 5s, B is the bottleneck\n- Diagnosis: replay binlog to diagnostic log with `performancesummary` and check Project Performance Summary — shows per-project time; grep for `node.*assigned` to check scheduling\n- Wide graphs (many independent projects) parallelize well; deep graphs (long chains) don't\n\n## Graph Build Mode (`\u002Fgraph`)\n\n- `dotnet build \u002Fgraph` or `msbuild \u002Fgraph`\n- What it changes: MSBuild constructs the full project dependency graph BEFORE building\n- Benefits: better scheduling, avoids redundant evaluations, enables isolated builds\n- Limitations: all projects must use `\u003CProjectReference>` (no programmatic MSBuild task references)\n- When to use: large solutions with many projects, CI builds\n- When NOT to use: projects that dynamically discover references at build time\n\n## Optimizing Project References\n\n- Reduce a `\u003CProjectReference>` only after proving it is unnecessary; a slow but\n  valid dependency must stay in the graph\n- Use `\u003CProjectReference ... SkipGetTargetFrameworkProperties=\"true\">` to avoid extra evaluations\n- `\u003CProjectReference ... ReferenceOutputAssembly=\"false\">` for build-order-only dependencies\n- Consider if a ProjectReference should be a PackageReference instead (pre-built NuGet)\n- Use `solution filters` (`.slnf`) to build subsets of the solution\n\n## BuildInParallel\n\n- `\u003CMSBuild Projects=\"@(ProjectsToBuild)\" BuildInParallel=\"true\" \u002F>` in custom targets\n- Without `BuildInParallel=\"true\"`, MSBuild task batches projects sequentially\n- Ensure `\u002Fmaxcpucount` > 1 for this to have effect\n\n## Multi-threaded MSBuild Tasks\n\n- Individual tasks can run multi-threaded within a single project build\n- Tasks implementing `IMultiThreadableTask` can run on multiple threads\n- Tasks must declare thread-safety via `[MSBuildMultiThreadableTask]`\n\n## Analyzing Parallelism with Binlog\n\n### Primary: binlog MCP (preferred)\n\nUse the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace):\n\n1. Use expensive_projects tool → find the slowest projects and compare individual vs total build time\n2. Use expensive_targets tool → find bottleneck targets\n3. Use project_target_times tool → drill into a specific project's target-level timing\n4. Ideal: build time should be much less than sum of project times (parallelism)\n5. If build time ≈ sum of project times: too many serial dependencies, or one slow project blocking others\n\n### Fallback: text-log replay (when MCP is unavailable)\n\nStep-by-step:\n\n1. Replay the binlog: `dotnet msbuild build.binlog -noconlog -fl \"-flp:v=diag;logfile=full.log;performancesummary\"`\n2. Check Project Performance Summary at the end of `full.log`\n3. Ideal: build time should be much less than sum of project times (parallelism)\n4. If build time ≈ sum of project times: too many serial dependencies, or one slow project blocking others\n5. `grep 'Target Performance Summary' -A 30 full.log` → find the bottleneck targets\n6. Consider splitting large projects or optimizing the critical path\n\n## CI\u002FCD Parallelism Tips\n\n- Use `-m` in CI (many CI runners have multiple cores)\n- Consider splitting solution into build stages for extreme parallelism\n- Use build caching (NuGet lock files, deterministic builds) to avoid rebuilding unchanged projects\n- `dotnet build \u002Fgraph` works well with structured CI pipelines\n",{"name":5,"license":15,"description":7},"main","8bdfc29f415696738d845d56aca5d438d0a068de",".agents\u002Fskills\u002Fbuild-parallelism",315,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 02:35:02",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add microsoft\u002Ftestfx --skill build-parallelism",{"tool":59,"command":60},"bunx","bunx skills add microsoft\u002Ftestfx --skill build-parallelism",{"tool":62,"command":63},"pnpm","pnpm dlx skills add microsoft\u002Ftestfx --skill build-parallelism","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbuild-parallelism\u002FSKILL.md",true,[],[68,95,125,144,161,185],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":39},"01M70GYY0AV0JGMTHE2CN6TNYK","dotnet-breaking-changes","Use before changing .NET\u002FC# code whose callers you do not control: a NuGet library, or a repo with PublicAPI.Shipped\u002FUnshipped.txt, ApiCompat, multiple TargetFrameworks, InternalsVisibleTo, or generated (.g.cs) partials. Green builds miss silent breaks from optional parameters, parameter names, sealing, const values, nullability, and #if. USE FOR: \"without breaking existing callers\"; adding a public method, overload, optional parameter, or interface member to a shipped library; renaming a public method or an internal helper a friend assembly uses; consolidating duplicated logic; changing a signature, nullability, default, or attribute; adding a target framework; RS0016\u002FRS0017 or ApiCompat errors; \"is this PR breaking?\". For a rename, extract, or merge, also invoke csharp-refactoring. DO NOT USE FOR: an executable whose callers all live in one project; renaming a local variable or private member, even in a shipped library; formatting; framework\u002FSDK\u002FNuGet upgrades (use dotnet-upgrade).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdotnet-breaking-changes\u002FSKILL.md",[],[75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94],"dotnet","dotnet breaking changes","changes","green","project","default","local","errors","interface","generated","upgrade","invoke","you","code","refactoring","merge","rename","library","live","assembly",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":106,"publishedAt":39},"01M699HHE9DTZWAMPB1ZR7ZKSW","testfx-test-value-evidence","Apply the vendored test-value-evidence skill with TestFx toolchain, assertion, parallel-safety, packed-consumer, and review conventions. Use when implementing or reviewing behavior-changing TestFx PRs or commits, including source-only changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-test-value-evidence\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[107,108,109,110,111,112,113,114,115,116,117,118,25,119,120,121,77,122,123,124],"test","testfx test value evidence","test value evidence","evidence","value","review","parallel","toolchain","commits","implementing","prs","only","when","apply","with","behavior","Safety","conventions",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":39},"01M699HEYWH1B9XGNBFY8J2FZS","testfx-parallel-safety-preflight","Check concurrency and isolation before implementing or refactoring TestFx tests, lifecycle code, helpers, shared-state declarations, or production paths those tests exercise. Use before narrowing DoNotParallelize or ResourceLock, changing parallelization settings, or introducing asynchronous workers; repeat against the final diff.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-parallel-safety-preflight\u002FSKILL.md",[],[132,123,133,113,134,135,116,136,88,137,89,30,138,139,140,141,142,143,25,24],"testfx parallel safety preflight","preflight","shared","asynchronous","exercise","concurrency","isolation","helpers","diff","parallelization","lifecycle","tests",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":39},"01M699HC61ZV9GJ2C8JV03951G","testfx-localization-validation","Validate generated TestFx localization catalogs, resource IDs, placeholders and locked tokens. Use for RESX\u002FXLF changes, OneLoc PRs, localization build failures, duplicate targets or units, and orphaned translation entries.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-localization-validation\u002FSKILL.md",[],[151,152,153,154,155,156,26,157,158,117,84,25,159,22,77,160,19],"testfx localization validation","validation","localization","validate","translation","ids","tokens","entries","units","targets",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":168,"publishedAt":39},"01M699H9J2NWQXE4BDT6R0FH7S","testfx-acceptance-validation","Validate TestFx shipping paths and capable CI execution using packed consumers, package\u002Fcache provenance, exact exits and artifacts, and selected-versus-executed test evidence. Use for acceptance regressions, package\u002FMSBuild\u002Flauncher\u002Fprotocol changes, or skipped-only CI results; not for unrelated unit-only or documentation changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-acceptance-validation\u002FSKILL.md",[167],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},[169,170,152,107,21,110,171,172,173,118,174,25,175,176,177,178,179,180,181,182,183,184,30,26],"testfx acceptance validation","acceptance","launcher","ci","execution","package","cache","artifacts","provenance","documentation","unrelated","shipping","results","protocol","unit","ci results",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":39},"01M699H70BB999BT4F627T1PHE","session-delivery-hygiene","Gate local-session scope, persistent delivery, live PR state, integration provenance, and owned cleanup. Use before implementing guidance changes, changing or pushing PR work, diagnosing package\u002Foutput mismatches, or handing off implementation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsession-delivery-hygiene\u002FSKILL.md",[],[192,193,194,195,196,116,81,197,32,93,198,174,25,177,199,200,77,201,202,203],"session delivery hygiene","delivery","session","hygiene","scope","cleanup","pr","output","state","integration","guidance","gate"]