Update to ModRetro Chromatic Plugin

{
  "name": "modretro-chromatic-rom-debugging",
  "description": "Build, inspect, and debug Game Boy or Game Boy Color ROMs. Use for native project or GBDK build failures, browser previews, direct emulator playtesting, and source or cartridge diagnostics.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 277
    },
    {
      "relative_path": "references/emulation-and-regression.md",
      "size_in_bytes": 9102
    },
    {
      "relative_path": "references/hardware-and-cartridge.md",
      "size_in_bytes": 8257
    }
  ],
  "skill_md_contents": "---\nname: modretro-chromatic-rom-debugging\ndescription: Build, inspect, and debug Game Boy or Game Boy Color ROMs. Use for native project or GBDK build failures, browser previews, direct emulator playtesting, and source or cartridge diagnostics.\n---\n\n# ModRetro Chromatic ROM debugging\n\nWork from the user's actual cartridge and project. Select the intended project\nexplicitly; an unconfigured `project_select` needs its absolute `.gbsproj` path,\nand `project_create` leaves it unselected unless called with `select:true`.\nNever fall back to the bundled starter. See the [project selection rules](../../docs/agent-guide.md#start-and-select-the-intended-project)\nwhen no authorized project or workspace is selected. If compiler or optional\nPyBoy availability is uncertain, use `toolchain_doctor`; report unavailable\nchecks rather than substituting a sample ROM or silently installing a runtime.\nUse authorized ROMs and output roots; preserve existing user saves and evidence.\n\nIf MCP cannot start or dependencies are missing, use the [setup skill](../modretro-chromatic-setup/SKILL.md).\nSelect build and/or emulator components for the requested checks; ROM inspection\nalone needs only the runtime.\n\n## Browser previews\n\nOpen every `web_preview` or `device_capture` URL, including screenshot Open links, only in **Codex's built-in browser**. If it is unavailable or blocked, retain the URL and report the concrete limitation. Never launch or fall back to an external browser.\n\nIf the browser is unavailable, locked or unreachable, retain its state and\ncontinue gameplay with the public PyBoy loop below on the intended exact ROM;\nbrowser access is not a prerequisite. Use the setup skill's `emulator` component\nif needed. Keep browser UI/annotation and physical-device/capture checks\nseparate. See [headless fallback](../../docs/stepped-playtesting.md#when-browser-play-is-unavailable)\nfor retained evidence and scoped failures.\n\nReuse the active preview URL or emulator/capture session for the same task. When temporary testing is complete, close only the session this task owns with `web_preview_close`, `emulator_close`, or `device_capture {\"action\":\"close\"}`. Preserve user play (including paused games), ongoing recordings, and unresolved saves or commands; inspect status and retain recovery evidence before closing. Never scan processes, kill by name, claim an unfamiliar port, or clean up another task's session. An unknown action is not safe to replay.\n\n### A preview URL refuses the connection\n\nPreview URLs belong to the MCP process that opened them. A plugin update,\nrestart, or fresh chat can leave an old browser tab pointing at a closed server.\nOn every platform, including Windows, inspect `web_preview {\"action\":\"status\"}`\nin the owning session before reusing a URL. A connection-refused page alone is\nnot evidence of browser policy, a missing emulator, or a device-driver problem.\n\nIf there is no live preview in the current session, select the user's original\nproject and call `web_preview {\"action\":\"recover\"}` to reopen its verified export without compiling. If no unchanged export exists, use `web_preview {}` to build and open it, then open the\nnewly returned URL. Do not invent the port, reuse a historical URL, or rebuild\nwith `force:true` just to reopen a server. Preserve any unresolved recording or\nsave from the old owner; opening a new preview does not recover unsaved state.\nIf a live listener is reported but the browser still fails, retain the exact\nerror and inspect the current owner; do not reset security settings or loop on\nreload. An explicit access refusal must not be bypassed through another caller.\n\n## Build and choose the right evidence\n\n- Build the selected project with `rom_build` and inspect its returned cartridge\n  with `rom_inspect`. Preserve compiler stderr and exit status on failures. A\n  classified official-CLI `DEP0190` is a known deprecation; a failed process,\n  missing/invalid ROM, or mismatched artifact is not a successful build. A GBDK\n  `sourcePath` probe proves only its C source compiled.\n- For direct model playtesting, use the optional PyBoy `emulator_*` tools. The\n  model making the change should choose each bounded input, inspect the actual\n  returned frames, and decide what to do next; the emulator stays paused between\n  calls.\n- For interactive human play or annotation, `web_preview {}` opens or reuses the\n  selected project's official Binjgb browser export. [Browser playback](references/emulation-and-regression.md#official-browser-play),\n  [saved progress](../../docs/agent-guide.md#saved-progress), and\n  [frame annotation](../../docs/agent-guide.md#annotate-a-game-preview) cover\n  those modes. A browser export, a native `rom_build`, PyBoy, and physical\n  hardware each establish different facts. For physical Chromatic play or\n  flashing, use [Chromatic deployment](../chromatic-deployment/SKILL.md).\n\n## Direct play and regression checks\n\nExample: hold right, add A for two frames, then release every button:\n\n```text\nemulator_run {\"romPath\":\"<absolute ROM outputPath returned by the build>\",\"restart\":true,\"initialFrames\":120}\nemulator_observe {}\nemulator_step {\"buttons\":[\"right\"],\"frames\":12,\"sampleCount\":4}\nemulator_step {\"buttons\":[\"right\",\"a\"],\"frames\":2,\"sampleCount\":2}\nemulator_step {\"buttons\":[],\"frames\":1,\"sampleCount\":1}\n```\n\nEvery step supplies the **complete held-button set** and advances 1–3,600\nframes. The set persists: repeated buttons stay held without a new press; `[]`\nreleases all buttons but still advances frames. `emulator_observe {}` is inert:\nit reads the genuine 160 × 144 framebuffer without advancing frames, delivering\ninput, or changing a recording. Use short steps near uncertain timings and\nconsecutive samples for flicker; a sampled frame proves nothing about gaps.\n\nIf images fail, check `execution` separately from `imageDelivery`. The input may\nhave advanced even if no image arrived or transport left execution unknown. Do\nnot repeat it to recover evidence; use inert observation or `emulator_review`\nof a retained interval. See [stepped playtesting](../../docs/stepped-playtesting.md)\nfor execution status, contact sheets, cancellation, and cleanup.\n\nPreserve the first failure and its inputs. After a source fix, build the new\ncartridge and repeat the relevant button sets and frame counts from comparable\nstarting conditions; inspect behavior separately from animation/hash changes.\nAn unchanged ROM reuses its session; use `restart:true` for an intentional fresh\nboot and `emulator_close {}` before selecting another project. Enable\n`recording:{}` on a fresh boot when the input history matters. For branching an\nexisting attempt, see [recordings and checkpoints](../../docs/recorded-playtesting.md):\nfirst send a neutral frame, and restore only into the identical ROM and runtime,\nincluding the worker hash. A checkpoint from before a rebuild cannot be used for\nthe regression run.\n\n## Diagnose and report\n\nFor named variables, the current scene, or authored collision/event references,\nbuild with `captureDebugArtifacts:true`, start that exact ROM with\n`debugMode:\"source\"`, and call `emulator_debug` while paused. It requires\nauthenticated same-build artifacts and unchanged source; unsupported or\noptimized-out data stays unavailable. For bounded OAM/VRAM/WRAM/HRAM inspection,\nuse `emulator_inspect`. See [hardware and source diagnostics](references/emulation-and-regression.md#bounded-hardware-and-source-diagnostics)\nor [cartridge headers, hardware limits, and common failures](references/hardware-and-cartridge.md).\n\nDistinguish authored source, typechecks or generated imagery, static dialogue or\nart previews, a compiled native cartridge, and actual observed runtime frames.\nNeither sampled images nor host-side throughput prove audio, saves, physical\nhardware behavior, or cartridge CPU-cycle performance. Report what ran, what\nthe frames showed, and what remains unverified. For host-specific setup, see\n[Windows setup](../../docs/windows-setup.md); Windows x64 is experimental and\nother-platform results do not validate it.\n"
}