Update to Gondwana

{
  "name": "create-gondwana-game",
  "description": "Builds or extends games, demos, samples, and gameplay features with the Gondwana C#/.NET game engine. Use when the user asks to make, create, scaffold, implement, port, or add a game or game mechanic with Gondwana, including requests such as \"make Pong with Gondwana\", \"create a platformer\", or \"add particles/collisions/input to my Gondwana game\".",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 432
    }
  ],
  "skill_md_contents": "---\r\nname: create-gondwana-game\r\ndescription: Builds or extends games, demos, samples, and gameplay features with the Gondwana C#/.NET game engine. Use when the user asks to make, create, scaffold, implement, port, or add a game or game mechanic with Gondwana, including requests such as \"make Pong with Gondwana\", \"create a platformer\", or \"add particles/collisions/input to my Gondwana game\".\r\n---\r\n\r\n# Create a Gondwana Game\r\n\r\nUse this skill for game-facing implementation with Gondwana.\r\n\r\nThe goal is not merely to produce plausible C# game code. Produce code that matches the **current Gondwana public API and intended architecture**.\r\n\r\n## Establish authoritative context\r\n\r\nBefore substantial implementation:\r\n\r\n1. If the Gondwana MCP tools are available, call `get_repository_info`.\r\n2. Read `AGENTS.md` from the current public/default Gondwana source unless the user explicitly names another ref.\r\n3. Read `docs/ai/README.md`.\r\n4. Inspect `Tooling/Gondwana.Templates/` for current project/startup conventions.\r\n5. Identify and inspect the closest current demo in `Demos/`.\r\n6. Search/read the source for the public types the implementation will use.\r\n7. Search/read the relevant wiki pages for the intended mental model.\r\n\r\nDo not invent an API because a similarly named method would be conventional in another game engine.\r\n\r\nIf live Gondwana repository access is unavailable, say that exact API verification is unavailable before relying on uncertain signatures.\r\n\r\n## Choose the closest existing path\r\n\r\nPrefer the nearest working Gondwana example:\r\n\r\n- Windows/WinForms game startup: inspect the current WinForms template and Windows demos.\r\n- Avalonia desktop: inspect current Avalonia hosting/examples.\r\n- Blazor/WebAssembly: inspect the current Blazor hosting/examples.\r\n- Platforming/collision gameplay: inspect `Demos/Gondwana.Platformer/`.\r\n- Ship movement/rotation/combat/HUD patterns: inspect `Demos/Gondwana.SpaceDuel/`.\r\n- Particles: inspect `Demos/Gondwana.ParticleTest/`.\r\n- Coordinate systems/projections: inspect `Demos/Gondwana.CoordinateTest/`.\r\n- Small game structure: inspect current compact demos such as `Demos/Gondwana.Flappy/`.\r\n- Widgets: inspect `Gondwana.Widgets/` and `Demos/WidgetsTest/`.\r\n\r\nDo not copy a stale demo pattern without checking the engine API it calls.\r\n\r\n## Implementation rules\r\n\r\n- Use public Gondwana APIs in game code.\r\n- Keep game-specific behavior in the game project.\r\n- Add core-engine behavior only when the requested capability genuinely belongs in Gondwana.\r\n- Preserve the code-first model; do not introduce an editor-owned workflow.\r\n- Respect package boundaries between core, hosting, widgets, adapters, optional packages, tooling, and demos.\r\n- Treat world, layer/grid, and screen coordinates as distinct spaces.\r\n- Account for the intentionally different bitmap and GPU rendering paths when rendering/invalidation is relevant.\r\n- Prefer straightforward sample code over abstraction created only to reduce a few repeated lines.\r\n\r\nWhen the request reveals a missing engine capability, separate the proposed engine change from the game/demo code so the user can evaluate the architectural addition explicitly.\r\n\r\n## Deliverables\r\n\r\nFor implementation requests, provide the smallest useful artifact that matches the user's workflow:\r\n\r\n- focused code snippets for small changes,\r\n- complete files for small self-contained examples,\r\n- an apply-ready patch when modifying an existing repository,\r\n- project boilerplate when creating a new game.\r\n\r\nInclude tests when changing reusable engine behavior. Demo-only gameplay does not need to become a core test unless it exposes a reusable regression.\r\n\r\n## Verification\r\n\r\nBefore claiming an implementation is correct:\r\n\r\n1. verify the exact public types/members used,\r\n2. check relevant tests,\r\n3. check the closest demo/template,\r\n4. account for lifecycle/ownership implications,\r\n5. build/test when the environment permits it.\r\n\r\nIf verification cannot be performed, state what remains unverified rather than presenting guessed API usage as current Gondwana code.\r\n"
}