build-parallelism
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 builds, incremental issues (use incremental-build), compilation slowness inside one project (use bu
npx skills add dotnet/skills --skill build-parallelism --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
## 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): 1. **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). 2. **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. 3. **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. 4. **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. 5. **Recommend flattening**: break false dependencies so independent projects build concurrently, and consider `/graph` for better scheduling. ## MSBuild Parallelism Model - `/maxcp
- Diagnose a slow parallel build (start here)
- MSBuild Parallelism Model
- Project Dependency Graph
- Graph Build Mode (/graph)
- Optimizing Project References
- BuildInParallel
- Multi-threaded MSBuild Tasks
- Analyzing Parallelism with Binlog
- Primary: binlog MCP (preferred)
- Fallback: text-log replay (when MCP is unavailable)
- CI/CD Parallelism Tips
What does the build-parallelism skill do?
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 builds, incremental issues (use incremental-build), compilation slowness inside one project (use bu
How do I install it?
Run `npx skills add dotnet/skills --skill build-parallelism --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From dotnet/skills, a repository with 4,927 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.