frb-build-verification

star 547

Verify FlatRedBall (FRB1) still compiles after editing Gum source it shares. Triggers: changes under GumCommon/ or MonoGameGum/Forms/, projitems sync, the FRB compile constant, CS0246/CS0103 from FRB. Only when a FlatRedBall checkout sits beside the Gum repo.

vchelaru By vchelaru schedule Updated 6/13/2026

name: frb-build-verification description: Verify FlatRedBall (FRB1) still compiles after editing Gum source it shares. Triggers: changes under GumCommon/ or MonoGameGum/Forms/, projitems sync, the FRB compile constant, CS0246/CS0103 from FRB. Only when a FlatRedBall checkout sits beside the Gum repo.

FRB Build Verification

FRB1 (FlatRedBall) compiles Gum source (not the DLLs) under a net6.0 target with the FRB constant defined, via shared .projitems. A change that builds fine in the Gum solutions can still break FRB1 — so when you touch shared source, build an FRB canary.

The projitems-sync rules (which files FRB1 pulls, and what to update when you add/rename/delete) live in .claude/agents/coder.md — read that, don't duplicate it here. This skill is only about running the build.

Precondition — skip entirely if absent

This is only doable when a FlatRedBall checkout exists as a sibling of the Gum repo (i.e. <gum-repo>/../FlatRedBall/). The cross-repo csproj imports are sibling-relative (..\..\..\..\FlatRedBall\…), so without that layout the build can't resolve. If the sibling is absent, skip FRB verification and say so — it is not a failure; the maintainer/CI covers it. Do not hardcode an absolute path; check for the sibling.

Must run from the PRIMARY checkout, never a worktree

The sibling-relative imports are computed from the csproj location, and the FlatRedBall-side csprojs pull Gum source by relative path into the primary Gum checkout (…\Gum\MonoGameGum\…). A worktree under .claude/worktrees/<branch>/ is both nested too deep (so ..\..\..\..\FlatRedBall resolves to nothing — MSB4019) and not the path FRB compiles from. To FRB-verify a branch, check that branch out in the primary Gum checkout and build there. Worktrees cannot FRB-verify.

Canaries

Pick by what you changed. Build from the primary Gum checkout (first row) / the sibling FlatRedBall repo (second row).

Changed source Build target Covers
GumCommon/ (anything in GumCoreShared.projitems) GumCore/GumCoreXnaPc/GumCore.DesktopGlNet6/GumCore.DesktopGlNet6.csproj GumCommon shared into FRB
MonoGameGum/Forms/ (in FlatRedBall.Forms.Shared.projitems) <FlatRedBall>/Engines/Forms/FlatRedBall.Forms/FlatRedBall.Forms.DesktopGlNet6/FlatRedBall.Forms.DesktopGlNet6.csproj Forms shared into FRB

GueDeriving/*Runtime, MonoGameGum/Renderables/, MonoGameGum/ExtensionMethods/, and the Forms/DefaultVisuals/ runtimes are not compiled by FRB1 (it generates its own) — changing only those needs no FRB build.

Interpreting results — baseline first

main is sometimes already red under FRB (e.g. a shared file gained a member that lives behind #if !FRB, or the FRB-side projitems is out of sync). So build the base branch first to capture the baseline errors, then build your branch and attribute only the new errors. A pre-existing error that survives on both is not yours to fix here (flag it separately).

Common genuinely-new breaks: a shared method/property guarded by #if !FRB referenced from un-guarded code (CS0103/CS0246), a .cs file added/renamed/deleted without updating the FRB-side projitems, or a net7.0+ BCL API used in shared source without an #if NET7_0_OR_GREATER gate (FRB multi-targets down to net6.0).

Install via CLI
npx skills add https://github.com/vchelaru/Gum --skill frb-build-verification
Repository Details
star Stars 547
call_split Forks 77
navigation Branch main
article Path SKILL.md
More from Creator