# Xnafiddle

> XnaFiddle

- Skill: `vchelaru/xnafiddle` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vchelaru/xnafiddle`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vchelaru/xnafiddle/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: vchelaru (https://skillmd.com/u/vchelaru)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vchelaru/xnafiddle

---


# XnaFiddle

**XnaFiddle is Victor's own site** (he maintains it) — so it's authoritative and feature-requestable, not a black-box third party. It lets you author a *fiddle*: a small project written in XNA syntax that compiles and runs in the browser.

## What it's for in Gum

Two jobs the checked-in `Samples/` projects don't cover as well:

1. **A source-linked, multi-platform engine experiment.** On **export** you choose the target runtime (**MonoGame / KNI / FNA**) and platforms (e.g. **desktop, web, Android** for KNI), and the export can **link against engine source** instead of the NuGet package — even emitting one `.slnx` with per-platform projects. This is what makes it possible to toggle an engine's build constants and prove *engine-side* behavior, not just observe the shipped build.
2. **A shareable public repro** for an upstream engine issue (KNI/MonoGame/FNA), so the maintainer can run it in a couple of clicks.

## Landmine — it is NOT a fixed prebuilt playground

The obvious assumption — "an online playground bakes in one engine, so you can't change the backend or its build" — is **wrong** for XnaFiddle. Because export chooses the runtime *and* can source-link, a fiddle can swap backends and run against engine source you control. Don't dismiss it as an investigation vehicle on the belief that it only observes a fixed build.

## Relationship to the local Gum samples

`Samples/KniGum*` (and the MonoGame/FNA equivalents) already reproduce across backends and link the **Gum runtime** from source, with the engine itself via NuGet — best when the question is "does Gum consume the shipped engine correctly." Reach for XnaFiddle when you instead need a self-contained **engine-source** experiment or a public repro: it's the stronger tool for *varying the engine*. For demoing a Gum-runtime feature itself, see the landmine below — it's a strong fit, not a weak one.

## Landmine — it already knows about Gum and 3rd-party libraries

Fiddles are Gum-aware, not engine-level-XNA-only — dozens of doc fiddles use the snippet `IsGum` flag (see `gum-docs-writing`'s `xnafiddle.md`). Referencing a 3rd-party library in a fiddle's source is enough to pull it in at export: each `ILibraryPlugin` (e.g. `KernSmithPlugin` in `XnaFiddle.Core/Plugins/`) auto-detects it via `IsUsedInSource` and adds the right NuGet packages — no manual "upgrade" needed. No plugin yet for a library? Request it rather than ruling the fiddle out.