version: "1.0.0" name: bt-build description: >- Fast incremental C++/MSBuild builds using bt. Use when the user wants to compile, build, check what's dirty, or query build dependencies in a repo that has .vcxproj files. Prefer bt over invoking MSBuild directly for inner-loop source changes (.cpp, .h, .idl, .xaml, .appxmanifest). allowed-tools: shell

bt — Fast Inner-Loop Builds

bt reads an MSBuild binary log and replays only the dirty compile/link/MIDL/XAML/makepri steps directly — no MSBuild overhead.

Use bt for the edit-build-debug cycle on source files only. For anything else, use the build skill (MSBuild).

Headers not yet in the tlog (newly added #includes) bt won't trigger rebuilds until the next msbuild -bl.

Do NOT use bt when

Any of these are true → use the build skill (MSBuild) instead:

• .vcxproj or .vcxitems files were added, removed, or edited
• .props or .targets files were changed
• NuGet package dependencies changed
• WinRT runtime classes were added or removed
• Packaging, signing, or AppX bundling is needed
• First build of the repo (no binlog exists yet)
• You are unsure whether bt covers the change

When in doubt, use MSBuild.

Before you start

1. Check if bt is installed

Run bt --version. If bt is missing, run the install-bt.ps1 script from this skill's directory to download and install it. Periodically run it to update bt as well.

2. Pick the right binlog

bt needs a binlog from a prior MSBuild build. The repo's build scripts all write to BuildOutput\ with names like:

<flavor> is amd64chk, arm64fre, etc. Single-project builds via msb/build-clang produce <project>.<flavor>.binlog next to these.

To pick:

1. Classify the change by edited paths — test (table below) / mux

(dxaml/xcp/ only) / product (everything else under controls/dev, controls/idl, dxaml/, src/).

1. Pick the freshest binlog whose scope covers that classification,

preferring broader scopes (product covers Controls, etc.).

1. Infer `<flavor>` from the chosen filename.
2. Pass `--binlog BuildOutput\<chosen>` to every bt invocation.

bt has no useful default to fall back to.

Caveats:

• On NTFS, Microsoft.UI.Xaml.<flavor>.binlog and

Microsoft.ui.xaml.<flavor>.binlog collide — content is whoever wrote last; trust mtime + size, not casing.

• If product and test binlogs exist with mtimes >1h apart, warn that the

set may be inconsistent.

• If no binlog exists, run the build skill.

Test path classification

Anything under these directories is test scope:

• controls/test/MUXControls.Test/
• controls/test/MUXControlsTestApp/
• controls/test/TabViewTearOutApp/
• controls/test/TestAppCX/
• controls/test/IXMPTestApp/
• controls/test/MUXTestInfra/ (if present)
• Samples/AppTestAutomationHelpers/

Common workflows

Run bt --help for command options (--binlog <path>), bt <subcommand> --help for subcommand options like -j <N>, --debounce <ms>, etc.