Diagnose and fix under-parallelized MSBuild builds. USE WHEN a multi-project solution build is slower than expected, doesn't speed up when you add cores, pegs a single core while others idle, or you want to know why `-m` isn't helping. Note: `/maxcpucount` default is 1 (sequential) — always pass `-m` for parallel builds. Covers finding the critical path (longest serial ProjectReference chain), graph build (`/graph`), BuildInParallel, and solution filters (`.slnf`). DO NOT USE FOR: single-project
SkillScore95Maintained
Automatic
◆Coding pack
Last verified 8/9/2026
What it changes
Passed 20 of 21 test cases with the skill, and 13 of 21 without it.
Without skill64%
With skill95%
Checks it passed that the model alone missed
Recommends calling expensive_targets
Recommends searching for node.*assigned
Recommends calling project_target_times
and 6 more in the full report
7 fixed14 passed either way1 still failing0 broke
Pass-rate lift
+32 pp
Tokens
+29%
Agent turns
0%
Response time
-74%
Model gemini-3.6-flashMeasured 8/9/2026v121 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
Using the `Microsoft.AITools.BinlogMcp` diagnostic server, which tool allows inspection of target-level execution durations for a single specific project?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends calling project_target_times
Missed
Passed
case-12 · gemini-3.6-flash · 8/9/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md94 linessingle file
Diagnose a slow parallel build (start here)
Work this checklist in order — it targets the usual root cause (a serial
dependency chain that no number of cores can parallelize):
Confirm parallelism is even on. Rebuild with dotnet build -m /bl:{}
(PowerShell: dotnet build -m -bl:{{}}). -m with no number uses all logical
processors; without -m MSBuild runs a single node (sequential).
Find the critical path. From the binlog, read per-project timings and the
node timeline. If total build time ≈ the sum of the projects on one
dependency chain, that chain — not CPU count — is the bottleneck.
Name the chain explicitly, e.g. Core → Api → Web → Tests. A long serial
chain stays serial no matter how large -m is, because each project waits on
its predecessor.
Look for unnecessary ProjectReference edges that lengthen the chain — a
reference that only needs build order (not the output assembly), or one that
could be a PackageReference, forces serialization it doesn't need.
Recommend flattening: break false dependencies so independent projects
build concurrently, and consider /graph for better scheduling.
MSBuild Parallelism Model
/maxcpucount (or -m): number of worker nodes (processes)
Default: 1 node (sequential!). Always use -m for parallel builds
Recommended: -m without a number = use all logical processors
Each node builds one project at a time
Projects are scheduled based on dependency graph
Project Dependency Graph
MSBuild builds projects in dependency order (topological sort)
Critical path: longest chain of dependent projects determines minimum build time
Bottleneck: if project A depends on B, C, D and B takes 60s while C and D take 5s, B is the bottleneck
Diagnosis: replay binlog to diagnostic log with performancesummary and check Project Performance Summary — shows per-project time; grep for node.*assigned to check scheduling
Detects MSBuild projects with conflicting OutputPath or IntermediateOutputPath. USE FOR: builds failing with 'Cannot create a file when that file already exists', 'The process cannot access the file because it is being used by another process', intermittent build failures that succeed on retry, or missing/overwritten outputs in multi-project or multi-targeting builds where bin/obj (or project.assets.json) collide. Common causes: shared OutputPath, missing AppendTargetFrameworkToOutputPath, extra