/binlog-generation
Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills,
Claude Code
$ npx -y skills add dotnet/skills --skill binlog-generation --agent claude-code
Codex
$ npx skills add dotnet/skills --skill binlog-generation -a codex -y
Cursor
$ npx skills add dotnet/skills --skill binlog-generation -a cursor -y
Gemini CLI
$ npx skills add dotnet/skills --skill binlog-generation -a gemini-cli -y
GitHub Copilot
$ npx skills add dotnet/skills --skill binlog-generation -a github-copilot -y
OpenCode
$ npx skills add dotnet/skills --skill binlog-generation -a opencode -y
Windsurf
$ npx skills add dotnet/skills --skill binlog-generation -a windsurf -y
SKILL.md
binlog-generation.SKILL.mdname: binlog-generation
description: "Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead), binlog MCP startup failures (use troubleshoot-binlog-mcp)."
license: MITGenerate Binary Logs
**Pass the `/bl` switch when running any MSBuild-based command.** This is a non-negotiable requirement for all .NET builds.
Commands That Require /bl
You MUST add the `/bl:{}` flag to:
- `dotnet build`
- `dotnet test`
- `dotnet pack`
- `dotnet publish`
- `dotnet restore`
- `msbuild` or `msbuild.exe`
- Any other command that invokes MSBuild
Preferred: Use `{}` for Automatic Unique Names
> **Note:** The `{}` placeholder requires MSBuild 17.8+ / .NET 8 SDK or later.
The `{}` placeholder in the binlog filename is replaced by MSBuild with a unique identifier, guaranteeing no two builds ever overwrite each other — without needing to track or check existing files.
# Every invocation produces a distinct file automatically
dotnet build /bl:{}
dotnet test /bl:{}
dotnet build --configuration Release /bl:{}**PowerShell requires quoting the complete switch:**
# Keep the literal {} placeholder in one argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'Why This Matters
1. **Unique names prevent overwrites** - You can always go back and analyze previous builds 2. **Failure analysis** - When a build fails, the binlog is already there for immediate analysis 3. **Comparison** - You can compare builds before and after changes 4. **No re-running builds** - You never need to re-run a failed build just to generate a binlog
Examples
# ✅ CORRECT - {} generates a unique name automatically (bash/cmd)
dotnet build /bl:{}
dotnet test /bl:{}
# ✅ CORRECT - quote the complete PowerShell argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'
# ❌ WRONG - Missing /bl flag entirely
dotnet build
dotnet test
# ❌ WRONG - No filename (overwrites the same msbuild.binlog every time)
dotnet build /bl
dotnet build /blOne build = one binlog
Add `/bl:{}` to **every** MSBuild invocation separately — never reuse a name and never rely on bare `/bl`:
- Building several configurations, projects, or retrying a failed build? Each
command still gets its own `/bl:{}` so the logs never overwrite each other.
dotnet build -c Debug /bl:{} # unique file
dotnet build -c Release /bl:{} # another unique fileVerify the binlog exists
After the build, confirm a `.binlog` was actually produced before moving on to analysis — a build that fails *before* MSBuild starts (e.g. a bad argument) writes no binlog:
ls -1 *.binlog # bash
dir /b *.binlog # Windows cmd
Get-ChildItem *.binlog # PowerShell
Note the resulting path so `binlog-failure-analysis` or `build-perf-diagnostics` can consume it.
When a Specific Filename Is Required
If the binlog filename needs to be known upfront (e.g., for CI artifact upload), or if `{}` is not available in the installed MSBuild version, pick a name that won't collide with existing files:
1. Check for existing `*.binlog` files in the directory 2. Choose a name not already taken (e.g., by incrementing a counter from the highest existing number)
# Example: directory contains 3.binlog — use 4.binlog
dotnet build /bl:4.binlog
Cleaning the Repository
When cleaning the repository with `git clean`, **always exclude binlog files** to preserve your build history:
# ✅ CORRECT - Exclude binlog files from cleaning
git clean -fdx -e "*.binlog"
# ❌ WRONG - This deletes binlog files (they're usually in .gitignore)
git clean -fdx
This is especially important when iterating on build fixes - you need the binlogs to analyze what changed between builds.
Read more
name: binlog-generation
description: "Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead), binlog MCP startup failures (use troubleshoot-binlog-mcp)."
license: MITGenerate Binary Logs
**Pass the `/bl` switch when running any MSBuild-based command.** This is a non-negotiable requirement for all .NET builds.
Commands That Require /bl
You MUST add the `/bl:{}` flag to:
- `dotnet build`
- `dotnet test`
- `dotnet pack`
- `dotnet publish`
- `dotnet restore`
- `msbuild` or `msbuild.exe`
- Any other command that invokes MSBuild
Preferred: Use `{}` for Automatic Unique Names
> **Note:** The `{}` placeholder requires MSBuild 17.8+ / .NET 8 SDK or later.
The `{}` placeholder in the binlog filename is replaced by MSBuild with a unique identifier, guaranteeing no two builds ever overwrite each other — without needing to track or check existing files.
# Every invocation produces a distinct file automatically
dotnet build /bl:{}
dotnet test /bl:{}
dotnet build --configuration Release /bl:{}**PowerShell requires quoting the complete switch:**
# Keep the literal {} placeholder in one argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'Why This Matters
1. **Unique names prevent overwrites** - You can always go back and analyze previous builds 2. **Failure analysis** - When a build fails, the binlog is already there for immediate analysis 3. **Comparison** - You can compare builds before and after changes 4. **No re-running builds** - You never need to re-run a failed build just to generate a binlog
Examples
# ✅ CORRECT - {} generates a unique name automatically (bash/cmd)
dotnet build /bl:{}
dotnet test /bl:{}
# ✅ CORRECT - quote the complete PowerShell argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'
# ❌ WRONG - Missing /bl flag entirely
dotnet build
dotnet test
# ❌ WRONG - No filename (overwrites the same msbuild.binlog every time)
dotnet build /bl
dotnet build /blOne build = one binlog
Add `/bl:{}` to **every** MSBuild invocation separately — never reuse a name and never rely on bare `/bl`:
- Building several configurations, projects, or retrying a failed build? Each
command still gets its own `/bl:{}` so the logs never overwrite each other.
dotnet build -c Debug /bl:{} # unique file
dotnet build -c Release /bl:{} # another unique fileVerify the binlog exists
After the build, confirm a `.binlog` was actually produced before moving on to analysis — a build that fails *before* MSBuild starts (e.g. a bad argument) writes no binlog:
ls -1 *.binlog # bash dir /b *.binlog # Windows cmd
Get-ChildItem *.binlog # PowerShell
Note the resulting path so `binlog-failure-analysis` or `build-perf-diagnostics` can consume it.
When a Specific Filename Is Required
If the binlog filename needs to be known upfront (e.g., for CI artifact upload), or if `{}` is not available in the installed MSBuild version, pick a name that won't collide with existing files:
1. Check for existing `*.binlog` files in the directory 2. Choose a name not already taken (e.g., by incrementing a counter from the highest existing number)
# Example: directory contains 3.binlog — use 4.binlog dotnet build /bl:4.binlog
Cleaning the Repository
When cleaning the repository with `git clean`, **always exclude binlog files** to preserve your build history:
# ✅ CORRECT - Exclude binlog files from cleaning git clean -fdx -e "*.binlog" # ❌ WRONG - This deletes binlog files (they're usually in .gitignore) git clean -fdx
This is especially important when iterating on build fixes - you need the binlogs to analyze what changed between builds.
This repository contains the .NET team's curated set of portable skills and host-specific custom agents for coding agents. For information about the Agent Skills standard, see agentskills.io.
Other skills on skills.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about binlog-generation.
- Which coding agents can use binlog-generation?
- binlog-generation installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

