How do I install the Xnafiddle skill?

Run npx skillmds@latest add vchelaru/xnafiddle in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Xnafiddle skill do?

XnaFiddle It is listed under Coding & Dev Tools on SkillMD.

Is Xnafiddle safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Xnafiddle?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Xnafiddle free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Xnafiddle?

vchelaru (@vchelaru) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Xnafiddle by vchelaru — Agent Skill

Name: Xnafiddle
Author: vchelaru

File contents

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:

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.
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.

---name: xnafiddledescription: 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 GumTwo 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 playgroundThe 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 librariesFiddles 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.

Frequently asked questions

Xnafiddle