eval-performance
Guide for diagnosing and improving MSBuild project evaluation performance. USE FOR: builds slow before any compilation starts, high evaluation time in binlog analysis, expensive glob patterns walking large directories (node_modules, .git, bin/obj), deep import chains (>20 levels), preprocessed output >10K lines indicating heavy evaluation, property functions with file I/O ($([System.IO.File]::ReadAllText(...))), multiple evaluations per project. Covers the 5 MSBuild evaluation phases, glob optimization via DefaultItemExcludes, import chain analysis with /pp preprocessing. DO NOT USE FOR: compi
Profile →npx skills add dotnet/skills --skill eval-performance --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.
# Diagnosing MSBuild Evaluation Performance Evaluation is the work MSBuild does *before* any target runs — reading project files, processing imports, expanding globs. This skill helps you **find and confirm** evaluation bottlenecks. Measure first; recommend a change only when a measurement proves it is warranted. ## Confirm the problem before changing anything Engage only when evaluation is *measurably* the bottleneck. Do NOT act when: - **The slowness is during compilation or target execution, not evaluation.** That is not an evaluation problem — use `build-perf-diagnostics` instead. - **The complaint is "rebuilds too much" / incremental build.** Use `incremental-build` instead. - **You have no measurement.** If no binlog or timing summary shows evaluation is slow, gather one first (see below). Do not guess from reading project files. - **A pattern below appears but evaluation is already fast.** Broad globs, deep imports, or `EnableDefaultItems` are only worth flagging when the numbers show they cost real time. A project that evaluates quickly needs no change. When a pattern is present but unmeasured, **report it as an observation and let the user decide** — do not rewrite working
- Confirm the problem before changing anything
- MSBuild Evaluation Phases
- Diagnosing Evaluation Performance
- Primary: binlog MCP (preferred)
- Fallback: text-log replay and preprocessing (when MCP is unavailable)
- Using binlog
- Using /pp (preprocess)
- Using /clp:PerformanceSummary
- Expensive Glob Patterns
- Import Chain Analysis
- Multiple Evaluations
- TreatAsLocalProperty
- Property Function Cost
- Optimization Checklist
What does the eval-performance skill do?
Guide for diagnosing and improving MSBuild project evaluation performance. USE FOR: builds slow before any compilation starts, high evaluation time in binlog analysis, expensive glob patterns walking large directories (node_modules, .git, bin/obj), deep import chains (>20 levels), preprocessed output >10K lines indicating heavy evaluation, property functions with file I/O ($([System.IO.File]::ReadAllText(...))), multiple evaluations per project. Covers the 5 MSBuild evaluation phases, glob optimization via DefaultItemExcludes, import chain analysis with /pp preprocessing. DO NOT USE FOR: compi
How do I install it?
Run `npx skills add dotnet/skills --skill eval-performance --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.