메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Gum tool C# code generation. Triggers: CodeGenerator, CodeOutputPlugin, generated code structure, .codsj settings, OutputLibrary selection, Forms codegen, state generation. For CLI/headless codegen see gum-cli.
Where runtime-feature demo screens go. Triggers: adding a sample/demo page for a new runtime feature, NineSliceScreen/SpriteScreen, shape demos, MonoGameGumInCode, Samples/raylib, SilkNetGum.
Forms DefaultVisuals — code-only visual classes backing Forms controls. Triggers: ButtonVisual, any *Visual class in DefaultVisuals/, Styling, DefaultFormsTemplates registration, custom code-only Forms visuals.
Building or modifying a Gum theme package (Themes/Gum.Themes.*) — restyling Forms controls by subclassing their V3 default visuals. Triggers: any file under Themes/, custom *Visual subclassing Gum.Forms.DefaultVisuals.V3.*, theme entry-point methods like EditorTheme.Apply / DarkProTheme.Apply.
Test-first discipline for Gum. Triggers: behavior changes (bug fix or feature) under GumCommon/, Gum/, MonoGameGum/, RenderingLibrary/, KniGum/, FnaGum/, SkiaGum/, RaylibGum/, Tools/Gum.ProjectServices/. Skip for docs, renames, csproj/projitems plumbing, style-only edits.
Unifying per-platform runtime files (MonoGame/Raylib/Skia/KNI/FNA, plus the Apos.Shapes ↔ SkiaGum shape-runtime pair) into one source with
| 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. |
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.
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.
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.
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.
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).
