Install the "build-perf-diagnostics" agent skill from https://github.com/microsoft/testfx/tree/main/.agents/skills/build-perf-diagnostics into .claude/skills/build-perf-diagnostics/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "build-perf-diagnostics", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add microsoft/testfx --skill build-perf-diagnostics -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "build-perf-diagnostics" agent skill from https://github.com/microsoft/testfx/tree/main/.agents/skills/build-perf-diagnostics into .agents/skills/build-perf-diagnostics/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "build-perf-diagnostics", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add microsoft/testfx --skill build-perf-diagnostics -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "build-perf-diagnostics" agent skill from https://github.com/microsoft/testfx/tree/main/.agents/skills/build-perf-diagnostics into .cursor/skills/build-perf-diagnostics/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "build-perf-diagnostics", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add microsoft/testfx --skill build-perf-diagnostics -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "build-perf-diagnostics" agent skill from https://github.com/microsoft/testfx/tree/main/.agents/skills/build-perf-diagnostics into .gemini/skills/build-perf-diagnostics/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "build-perf-diagnostics", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add microsoft/testfx --skill build-perf-diagnostics -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "build-perf-diagnostics" agent skill from https://github.com/microsoft/testfx/tree/main/.agents/skills/build-perf-diagnostics into .github/skills/build-perf-diagnostics/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "build-perf-diagnostics", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add microsoft/testfx --skill build-perf-diagnostics -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "build-perf-diagnostics" agent skill from https://github.com/microsoft/testfx/tree/main/.agents/skills/build-perf-diagnostics into .opencode/skills/build-perf-diagnostics/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "build-perf-diagnostics", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
Skill name
build-perf-diagnostics
GitHub stars
1k
Used in
2 other repos
Token cost
~2.6k tokens
SKILL.md length
958 words
Files
1
Skills in repo
44
Repo updated
First seen
Licence
MIT
At a glance
Diagnose MSBuild build performance bottlenecks using binary log analysis.
Works in 7 steps: ResolveAssemblyReference (RAR) Slowness → Roslyn Analyzers and Source Generators → Serialization Bottlenecks… → …
: identifying why builds are slow by analyzing binlog performance summaries
SKILL.md covers Performance Analysis Methodology, Key Metrics and Thresholds, Common Bottlenecks and Using Binlog Replay for…, plus 2 more sections
Calls dotnet
What it does
Build Perf Diagnostics is an agent skill from microsoft/testfx, published by the product's own GitHub organization. Diagnose MSBuild build performance bottlenecks using binary log analysis. USE FOR: identifying why builds are slow by analyzing binlog performance summaries, detecting ResolveAssemblyReference (RAR) taking 5s, Roslyn analyzers consuming 30% of Csc time, single targets dominating 50% of build time, node utilization below 80%, excessive Copy tasks, NuGet restore running every build. Covers timeline analysis, Target/Task Performance Summary interpretation, and 7 common bottleneck categories. Use after…
Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Development. It works with Model Context Protocol and .NET. The repository describes itself as: This repository holds the source code of Microsoft.Testing.Platform (MTP), a lightweight alternative to VSTest, as well as MSTest adapter and framework. The licence is MIT.
When your agent uses it
: identifying why builds are slow by analyzing binlog performance summaries
Read from SKILL.md and the folder at commit 44b9dcc. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
dotnet
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Build Perf Diagnostics loads about 2.6k tokens when it runs. Until then it costs about 197 tokens; SKILL.md has 958 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~197
When it runs· the whole SKILL.md, loaded when a task matches
~2.6k
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
Download SKILL.mdSave it as .claude/skills/build-perf-diagnostics/SKILL.md (or your agent's skills folder).
name
build-perf-diagnostics
description
Diagnose MSBuild build performance bottlenecks using binary log analysis. USE FOR: identifying why builds are slow by analyzing binlog performance summaries, detecting ResolveAssemblyReference (RAR) taking >5s, Roslyn analyzers consuming >30% of Csc time, single targets dominating >50% of build time, node utilization below 80%, excessive Copy tasks, NuGet restore running every build. Covers timeline analysis, Target/Task Performance Summary interpretation, and 7 common bottleneck categories. Use after build-perf-baseline has established measurements. DO NOT USE FOR: establishing initial baselines (use build-perf-baseline first), fixing incremental build issues (use incremental-build), parallelism tuning (use build-parallelism), non-MSBuild build systems.
license
MIT
Performance Analysis Methodology
Generate a binlog: dotnet build /bl:{} -m
Use the binlog MCP server (Microsoft.AITools.BinlogMcp, exposed under the binlog MCP namespace) which is bundled with this plugin
Alternate flow when MCP is unavailable: binlog replay to text logs
Generate a binlog: dotnet build /bl:{} -m
Replay to diagnostic log with performance summary:bash
Build duration: what's "normal" — small project <10s, medium <60s, large <5min
Node utilization: ideal is >80% active time across nodes. Low utilization = serialization bottleneck
Single target domination: if one target is >50% of build time, investigate
Analyzer time vs compile time: analyzers should be <30% of Csc task time. If higher, consider removing expensive analyzers
RAR time: ResolveAssemblyReference >5s is concerning. >15s is pathological
Common Bottlenecks
1. ResolveAssemblyReference (RAR) Slowness
Symptoms: RAR taking >5s per project
Root causes: too many assembly references, network-based reference paths, large assembly search paths
Fixes: reduce reference count, use <DesignTimeBuild>false</DesignTimeBuild> for RAR-heavy analysis, set <ResolveAssemblyReferencesSilent>true</ResolveAssemblyReferencesSilent> for diagnostic
Advanced: <DesignTimeBuild> and <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
Key insight: RAR runs unconditionally even on incremental builds because users may have installed targeting packs or GACed assemblies (see dotnet/msbuild#2015). With .NET Core micro-assemblies, the reference count is often very high.
Reduce transitive references: Set <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences> to avoid pulling in the full transitive closure (note: projects may need to add direct references for any types they consume). Use ReferenceOutputAssembly="false" on ProjectReferences that are only needed at build time (not API surface). Trim unused PackageReferences.
2. Roslyn Analyzers and Source Generators
Symptoms: Csc task takes much longer than expected for file count (>2× clean compile time)
Diagnosis: Check the Task Performance Summary in the replayed log for Csc task time; grep for analyzer timing messages; compare Csc duration with and without analyzers (/p:RunAnalyzers=false)
Fixes:
Conditionally disable in dev: <RunAnalyzers Condition="'$(ContinuousIntegrationBuild)' != 'true'">false</RunAnalyzers>
Remove genuinely redundant analyzers from inner loop
Severity config in .editorconfig for less critical rules
Key principle: Preserve analyzer enforcement in CI. Never just "remove" analyzers — configure them conditionally.
GlobalPackageReference: Analyzers added via GlobalPackageReference in Directory.Packages.props apply to ALL projects. Consider if test projects need the same analyzer set as production code.
EnforceCodeStyleInBuild: When set to true in Directory.Build.props, forces code-style analysis on every build. Should be conditional on CI environment (ContinuousIntegrationBuild) to avoid slowing dev inner loop.
Symptoms: Performance summary shows most build time concentrated in a single project; diagnostic log shows idle nodes while one works
Common culprits: targets without proper dependency declaration, single project on critical path
Fixes: split large projects, optimize the critical path project, ensure proper BuildInParallel
4. Excessive File I/O (Copy tasks)
Symptoms: Copy task shows high aggregate time
Root causes: copying thousands of files, copying across network drives, Copy task unintentionally running once per item (per-file) instead of as a single batch (see dotnet/msbuild#12884)
Fixes: use hardlinks (<CreateHardLinksForCopyFilesToOutputDirectoryIfPossible>true</CreateHardLinksForCopyFilesToOutputDirectoryIfPossible>), reduce CopyToOutputDirectory items, use <UseCommonOutputDirectory>true</UseCommonOutputDirectory> when appropriate, set <SkipCopyUnchangedFiles>true</SkipCopyUnchangedFiles>, consider --artifacts-path (.NET 8+) for centralized output layout
Dev Drive: On Windows, switching to a Dev Drive (ReFS with copy-on-write and reduced Defender scans) can significantly reduce file I/O overhead for Copy-heavy builds. Recommend for both dev machines and self-hosted CI agents.
Show full SKILL.md (433 more words)Show less
5. Evaluation Overhead
Symptoms: build starts slow before any compilation
Root causes: complex Directory.Build.props, wildcard globs scanning large directories, NuGetSdkResolver overhead (adds 180-400ms per project evaluation even when restored — see dotnet/msbuild#4025)
Fixes: reduce Directory.Build.props complexity, use <EnableDefaultItems>false</EnableDefaultItems> for legacy projects with explicit file lists, avoid NuGet-based SDK resolvers if possible
See: eval-performance skill for detailed guidance
6. NuGet Restore in Build
Symptoms: restore runs every build even when unnecessary
Fixes:
Separate restore from build: dotnet restore then dotnet build --no-restore
Enable static graph evaluation: <RestoreUseStaticGraphEvaluation>true</RestoreUseStaticGraphEvaluation> in Directory.Build.props — can save significant time in large builds (results are workload-dependent)
7. Large Project Count and Graph Shape
Symptoms: many small projects, each takes minimal time but overhead adds up; deep dependency chains serialize the build
Consider: project consolidation, or use /graph mode for better scheduling
Graph shape matters: a wide dependency graph (few levels, many parallel branches) builds faster than a deep one (many levels, serialized). Refactoring from deep to wide can yield significant improvements in both clean and incremental build times.
Actions: look for unnecessary project dependencies, consider splitting a bottleneck project into two, or merging small leaf projects
We found 3 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 2 other GitHub owners. This page covers the copy in microsoft/testfx, which our catalogue first saw on October 7, 2026.
Build Perf Diagnostics next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
Build Perf Diagnostics compared with similar skills
Review pull requests in mcp-windows for concrete bugs in MCP and CLI contracts, Windows UI automation, element identity, snapshots, bounded searches, and service lifetime.
A skill your agent uses when investigating, developing, debugging, testing, or reviewing Aspire VS Code extension behavior under extension/, including extension UI, command, debugger, RPC, DCP, MCP…
Make Sentry stack traces readable — upload source maps for JavaScript/TypeScript, or debug files for native and mobile (dSYM, ProGuard/R8, NDK symbols, Dart obfuscation maps, .NET PDBs).
Diagnose MSBuild build performance bottlenecks using binary log analysis. Build Perf Diagnostics is an agent skill from microsoft/testfx, published by the product's own GitHub organization. Diagnose MSBuild build performance bottlenecks using binary log analysis.
When should I use Build Perf Diagnostics?
Build Perf Diagnostics fits situations like: : identifying why builds are slow by analyzing binlog performance summaries; detecting ResolveAssemblyReference (RAR) taking 5s; roslyn analyzers consuming 30% of Csc time; single targets dominating 50% of build time.
How do I install Build Perf Diagnostics in Claude Code?
Run `npx skills add microsoft/testfx --skill build-perf-diagnostics -a claude-code`. Or copy the skill folder (.agents/skills/build-perf-diagnostics in microsoft/testfx) into .claude/skills/build-perf-diagnostics in your project. Claude Code loads it when a task matches its description.
How do I install Build Perf Diagnostics in Codex?
Run `npx skills add microsoft/testfx --skill build-perf-diagnostics -a codex`. Or copy the skill folder (.agents/skills/build-perf-diagnostics in microsoft/testfx) into .agents/skills/build-perf-diagnostics in your project. Codex loads it when a task matches its description.
Can I use Build Perf Diagnostics in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add microsoft/testfx --skill build-perf-diagnostics -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/build-perf-diagnostics, .gemini/skills/build-perf-diagnostics, .github/skills/build-perf-diagnostics and .opencode/skills/build-perf-diagnostics in your project.
What does Build Perf Diagnostics need to run?
Going by SKILL.md and its folder, Build Perf Diagnostics needs the command-line tools its instructions call (dotnet).
Does Build Perf Diagnostics access the network?
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Is Build Perf Diagnostics safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Build Perf Diagnostics use?
Build Perf Diagnostics is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Build Perf Diagnostics use?
About 2.6k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Build Perf Diagnostics?
Skills that share tags, products or a category with Build Perf Diagnostics: Dotnet Debugging (novotnyllc/dotnet-artisan, 233 stars), Roslynk (mrpmorris/Roslynk, 122 stars), Code Review (sbroenne/mcp-windows, 105 stars) and Vscode Extension (microsoft/aspire, 6.3k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Build Perf Diagnostics?
microsoft (a GitHub organization, an official publisher) maintains it in microsoft/testfx, which has 1,047 GitHub stars. The repository holds 44 skills in this directory. The repository was last updated on October 7, 2026.
Source: microsoft/testfx on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.
