Add build.ps1 + bridge/build.ps1 wrappers and Claude Code build skills

[Kim2091]

As promised, here are the Claude build skills from Remix Plus. This also includes a fix for a common issue people run into in the main build script.

Summary

Adds build.ps1 (runtime) and bridge/build.ps1 (bridge) — PowerShell wrappers around the existing meson/ninja build flow that address two known build issues:

1. Stale install-target directories. The runtime install writes to nv-private/ and tests/rtx/dxvk_rt_testing/. Stale content left in those directories from a prior build can cause subsequent installs to behave incorrectly. build.ps1 pre-clears both before every install — this is the load-bearing fix the wrapper exists for.
2. Silent SetupVS failure. When the detected Visual Studio install is missing the C++ build tools workload, vcvarsall.bat lookup silently no-ops (cmd writes 'vcvarsall.bat' is not recognized to stderr, but the script continues with no VC env loaded); meson then surfaces a cryptic cl.exe not found later, hiding the real cause. Under build_bridge_release.bat it's worse — the .bat captures cmd's empty stdout and exits 0 with no x86 client output. The wrappers resolve vcvarsall.bat by full path with a Test-Path guard, so the missing workload fails loudly at the wrapper instead.

Plus two .claude/skills/ files documenting the canonical invocation for LLM-driven contributor workflows.

Both wrappers are additive — build_dxvk.ps1, build_common.ps1, and bridge/build_bridge_*.bat are untouched, so existing CI and docs keep working.

What the wrappers do

• Pre-clear nv-private/ and tests/rtx/dxvk_rt_testing/ before each runtime build. These are untracked install-target directories that meson regenerates; stale content there causes the issue called out above. Known-issue workaround.
• Resolve Visual Studio via vswhere and Test-Path-validate the install before doing anything else.
• Invoke vcvarsall.bat by full path (call "$vcvars") so a missing C++ workload fails loudly at the wrapper, not later in meson.
• Run meson setup / compile / install in a single isolated cmd.exe shell so VS env stays consistent across the chain.
• Stream output to the PowerShell pipeline.
• Verify expected build artifacts exist before reporting success.
• Optional auto-deploy.local.ps1 at repo root (gitignored) for contributors who want successful builds copied to a test game install. No-op when the file doesn't exist.

Parameters

build.ps1: -Flavor release|debug|debugoptimized, -EnableTracy, -Clean

bridge/build.ps1: -Flavor release|debug|debugoptimized, -Arch x64|x86|both (default both), -Clean

Skills

.claude/skills/{rtx-build,bridge-build}/SKILL.md are content files consumed by Claude Code / similar LLM tooling. They document the canonical invocation, when to invoke (and when not to), expected duration, success / error report patterns, and known-non-failure warnings (LNK4098, etc.). No effect on the build itself.

Testing

Tested against a fresh shallow clone of main with all submodules at --depth=1 --init --recursive:

Run	Result
build.ps1 -Flavor release cold	green, both artifacts produced
build.ps1 -Flavor release 2nd pass	green
build.ps1 -Flavor release 3rd pass with cleanup active	green — install dirs regenerated cleanly after pre-clear
bridge/build.ps1 -Flavor release -Arch both cold	green, all three artifacts (x64 server, x86 client, x86 launcher)
bridge/build.ps1 -Flavor release -Arch both 2nd pass	green

Zero compile errors, zero linker errors, zero matches for error C\d|fatal error|FAILED:|ninja: build stopped|cl\.exe not found|vcvarsall.*not recognized.

[MarkEHenderson]

We already have several skills files in .agents/skills/. new skills files should go there, and if a given agent doesn't read those files by default, it'd be good to have something to point them to it (It looks like this may require manual configuration with Claude, but I'm not sure)

[MarkEHenderson]

Is there a reason the existing build scripts can't be upgraded with these advantages, rather than introducing a new wrapper around them?

[Kim2091]

They very well can be if that's preferred! I wasn't sure if the original build scripts should be touched or not due to internal workflows or other similar things.

[Kim2091]

We already have several skills files in .agents/skills/. new skills files should go there, and if a given agent doesn't read those files by default, it'd be good to have something to point them to it (It looks like this may require manual configuration with Claude, but I'm not sure)

Claude does read the .claude folder by default, and it parses skills a bit differently than most agents. I'll see if I can find a workaround