Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add managedcode/dotnet-skills --skill build-perf-diagnosticsgit clone --depth 1 https://github.com/managedcode/dotnet-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/managedcode/dotnet-skills/build-perf-diagnostics)<a href="https://agentmods.dev/skills/managedcode/dotnet-skills/build-perf-diagnostics"><img src="https://agentmods.dev/badge/skills/managedcode/dotnet-skills/build-perf-diagnostics/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/managedcode/dotnet-skills/build-perf-diagnostics"><img src="https://agentmods.dev/badge/skills/managedcode/dotnet-skills/build-perf-diagnostics.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00160 | $0.02429 |
| Opus 5 | $0.00080 | $0.01215 |
| Sonnet 5 | $0.00032 | $0.00486 |
| Haiku 4.5 | $0.00016 | $0.00243 |
Grade A, and why
build-perf-diagnostics scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to build-perf-diagnostics — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Performance Analysis Methodology
- Generate a binlog:
dotnet build /bl:{} -m - Use the binlog MCP server (
Microsoft.AITools.BinlogMcp, exposed under thebinlogMCP 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:
dotnet msbuild build.binlog -noconlog -fl -flp:v=diag;logfile=full.log;performancesummary - Read the performance summary (at the end of
full.log):grep "Target Performance Summary\|Task Performance Summary" -A 50 full.log - Find expensive targets and tasks: The PerformanceSummary section lists all targets/tasks sorted by cumulative time
- Check for node utilization: grep for scheduling and node messages
grep -i "node.*assigned\|building with\|scheduler" full.log | head -30 - Check analyzers: grep for analyzer timing
grep -i "analyzer.*elapsed\|Total analyzer execution time\|CompilerAnalyzerDriver" full.log
Key Metrics and Thresholds
- 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). UseReferenceOutputAssembly="false"on ProjectReferences that are only needed at build time (not API surface). Trim unused PackageReferences.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 151 lines · 160 tokens per session scan A 8575541b9b13
build-perf-diagnostics is a skill published in the GitHub repository managedcode/dotnet-skills (477 stars, last pushed 4d ago), licensed MIT. It adds 160 tokens to every session and 2,429 once invoked, about $0.0008 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to build-perf-diagnostics, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
cs0618-hunter
Detects and fixes CS0618 obsolete API warnings in .NET builds. The compiler is the authoritative source for what your project actually triggers — it catches transitive obsoletions, overload-resolution surprises, and project-local [Obsolete] attributes that static inspection cannot see. Pair with the repository-pinned…
nuget-diff-analyzer
Post-processes the repository-pinned [email protected] -- diff output into a categorised report (breaking / additive / newly-obsolete) with each finding cross-referenced to the MAF obsolete-API registry.
agents-sdk-dotnet-debugging
Use when troubleshooting an agent built with the Microsoft Agents SDK (Microsoft.Agents.Hosting.AspNetCore and related packages) in C# / .NET. Trigger on any of these symptoms: build or C# compile errors, crashes on startup, 401 or auth errors on incoming requests, the bot not responding to messages, appsettings.json…
winui-setup
Install and verify the prerequisites the win-dev-skills WinUI 3 toolchain depends on — .NET SDK 8.0.100+, WinApp CLI 0.6+, and Developer Mode. Use only when the user explicitly asks to set up or repair the toolchain. Do not invoke automatically when another skill reports a missing prerequisite; tell the user what is…
winui-wpf-migration
Migrate WPF applications to WinUI 3 — namespace replacement (System.Windows → Microsoft.UI.Xaml), control mapping (DataGrid→ListView, WrapPanel→ItemsRepeater, TabControl→TabView), threading (Dispatcher→DispatcherQueue), imaging (System.Drawing→BitmapImage), MVVM conversion to CommunityToolkit.Mvvm, and…
roslyn-codelens
Use when working with any .NET / C# code (.cs/.csproj/.sln/.slnx files), finding callers/references/implementations, checking compiler errors or warnings, running dotnet build for diagnostics, searching for a type/method/interface by name, inspecting DI registrations, detecting dead code or circular dependencies…