build-parallelism

Diagnose and optimize MSBuild build parallelism across multi-project .NET solutions.

1|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/D1ssolve/craft-agents --skill build-parallelism-d1ssolve
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: build-parallelism
Source: https://github.com/D1ssolve/craft-agents/tree/main/skills/build-parallelism
Command: npx skills add https://github.com/D1ssolve/craft-agents --skill build-parallelism-d1ssolve

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Multi-project .NET solutions often build sequentially or leave CPU cores idle because MSBuild defaults to a single worker node, and long dependency chains create bottlenecks that are hard to see without analysis. ## Core Features & Use Cases - Parallelism Configuration: Guides correct use of -m /maxcpucount, graph build mode (/graph), and BuildInParallel on the MSBuild task. - Dependency Graph Optimization: Reduces unnecessary ProjectReference entries, applies solution filters (.slnf), and identifies critical-path bottlenecks. - Binlog-Based Diagnosis: Uses the binlog MCP server tools (expensive_projects, expensive_targets, project_target_times) with a text-log replay fallback to find slow projects and targets. - Use Case: A CI pipeline builds a 60-project solution in 20 minutes despite a multi-core runner; this Skill identifies that -m was missing and that one 60-second project blocks the critical path. ## Quick Start Analyze my solution's build.binlog and tell me why the build is not using all CPU cores and how to speed it up.

Frequently Asked Questions about build-parallelism

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make MSBuild use all CPU cores?

Pass -m (or /maxcpucount) to dotnet build or msbuild, since the default is a single worker node and builds run sequentially without it. Using -m without a number uses all logical processors.

What does dotnet build /graph do?

The /graph flag makes MSBuild construct the full project dependency graph before building, enabling better scheduling, avoiding redundant evaluations, and supporting isolated builds. It requires all references to be ProjectReference entries, not dynamic MSBuild task references.

Why is my build not faster even with the -m flag?

Parallelism is limited by the dependency graph: long chains of dependent projects serialize the build, and one slow project on the critical path blocks everything downstream. Replay the binlog with performance summaries to find the bottleneck project.

How do I find which project slows down my solution build?

Use the binlog MCP server tools: expensive_projects shows the slowest projects, expensive_targets shows bottleneck targets, and project_target_times drills into one project. Without MCP, replay the binlog to a diagnostic text log and check the Project Performance Summary.

When should I not use graph build mode?

Avoid /graph when projects dynamically discover references at build time through programmatic MSBuild task references, since graph mode requires static ProjectReference entries. It is also unnecessary for single-project builds.

How do solution filters help build performance?

Solution filters (.slnf) let you build only a subset of projects in a large solution, skipping unrelated projects entirely. This reduces both the dependency graph size and total build time for targeted work.