{"owner":"libretro","repo":"RetroArch","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":2697,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"RetroArch":{"command":"npx","args":["-y","@modelcontextprotocol/server-RetroArch"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"AGENTS.md\n\n## Project\n\nRetroArch is primarily written in C89. Preserve the existing language and style of the file being edited.\n\n- New C code must be C89-compatible unless the surrounding code explicitly requires otherwise.\n- Do not introduce C99/C11 features into C89 code.\n- Existing files written in C++, Objective-C, or another language should remain in that language.\n- Follow the conventions of surrounding code rather than introducing a new style.\n- Prefer the smallest change that completely solves the task.\n- Preserve existing architecture\n\nRead CODING-GUIDELINES before changing code: brace style, declarations,\nstack budgets and the never-block rule for the main thread are there.\nSubdirectories with rules of their own carry their own AGENTS.md.\n`tools/compile_commands.py`, after ./configure, writes compile_commands.json\nfor clangd and other code navigation.\n\n## Threads\n\n- Nothing may block: no sleeping, busy-waiting, wait-for-idle or round-trip\n  waits, least of all in the threaded video wrapper and the audio pipeline.\n  A design that needs to block is shaped wrong.\n- Do not add locks. Use retro_atomic.h, the SPSC rings (retro_spsc.h,\n  retro_waitable_spsc.h) and retro_eventcount.h.\n- Guard threaded code with HAVE_THREADS, and check it with a full\n  `./configure --disable-threads` build that links, not a single TU.\n- No logging inside pacing or sync paths.\n\nRetroArch contains deliberately complex, cross-file systems. Do not simplify, consolidate, refactor, or redesign an existing subsystem merely because its structure appears unnecessarily complicated.\n\nComplexity may exist for compatibility, platform, driver, or architectural reasons.\n\nWhen implementing a feature, find an existing feature with similar behavior and follow its implementation pattern. The current source tree takes precedence over historical examples.\n\nDo not make unrelated cleanup or refactoring changes.\n\n## Comments\n\nKeep comments as short as possible.\n\n- Prefer no comment when the code is self-explanatory.\n- When a comment is necessary, prefer a few words or a few lines at most.\n- Explain why something is non-obvious, rather than describing what obvious code does.\n- Do not add comments merely because code was changed.\n- Do not describe the previous implementation or behavior unless that historical context is necessary to understand the current code.\n- Do not use comments as miniature documentation or change logs.\n- Prefer clear names and straightforward code over explanatory comments.\n\nComments should describe information that will remain useful after the current change is forgotten.\n\n## Commit messages\n\nKeep commit messages concise and focused.\n\n- Explain what changed and why.\n- Prefer a short subject line and a brief body when additional context is useful.\n- Do not enumerate every changed file or implementation detail.\n- Do not describe intermediate attempts, discarded approaches, or the development process.\n- Do not explain the previous implementation unless it is necessary to understand the change.\n- Keep the complete commit message below approximately 600 words.\n- A commit message is not a changelog or development diary.\n\n## Menu changes\n\nAdding or modifying a menu option commonly requires changes in several parts of the codebase.\n\nDo not assume that a menu option can be implemented by modifying only the file where it is displayed.\n\n### Before adding a menu option:\n\n- Find an existing menu option with similar behavior.\n- Trace its complete implementation through the menu, settings, configuration, and message systems.\n- Identify every part of that pattern that applies to the new option.\n- Implement the new option consistently across all required layers.\n- Do not modify unrelated menu code.\n\n#### Useful reference commits:\n\n- 6e9aa66aea2b2b3d0687585e41bac658ac9ae252 — SMB timeout/context settings exposed as menu options.\n- 434f41b935232325ed13024786653f9dfef49643 — CRT menu additions.\n- 23170b82ec58c2b283a7132b85fa73e18050a5ae — MIDI device dropdown menu items.\n05faba73e3fed69a5e118df2cc28d31309089243 — menu implementation example.\n\nThese are reference implementations, not fixed lists of files to modify. The required files depend on the feature.\n\n## Shader and video backend changes\n\nShader functionality frequently crosses shared shader code and multiple video backends.\n\n### When adding or modifying shader functionality:\n\n- Find an existing shader feature with similar behavior.\n- Trace the feature through the shared shader infrastructure.\n- Identify every applicable shader implementation and video backend.\n- Keep backend implementations consistent where the feature is supported.\n- Do not update only the backend currently being tested if the feature is expected to work elsewhere.\n- Check platform/backend-specific differences rather than blindly duplicating code.\n\n#### Useful reference commits:\n\n- da5ecaa45a862e51783eca1280f46fbfb7984ede — OriginalAspect and OriginalAspectRot uniforms.\n- 2a56a827e8a97a3838a9d455f1dca442c0ffbb07 — frametime/original-FPS shader uniforms.\n- 37cfa4857d064464754e800bad89ce69e81230fe — sensor shader uniforms across multiple shader and video/input backends.\n\nThese commits demonstrate the breadth of changes that may be required. They are examples of implementation patterns, not instructions to reproduce their exact file lists.\n\n## Historical commits\n\nHistorical commits may be used to understand established implementation patterns.\n\n- Treat examples as references, not specifications.\n- Prefer the current source tree when it differs from an historical commit.\n- Do not copy historical changes mechanically.\n- Do not reproduce obsolete workarounds merely because they appear in an old commit.\n- Inspect surrounding current code before applying a historical pattern.\n\n## Regression tests\n\nRegression tests must build on both Windows and Linux.\n\n- Do not use POSIX-only or Win32-only headers or APIs in test code without a working path for the other platform; prefer libretro-common facilities.\n- Check that the test builds with a Linux toolchain and with mingw-w64 (MSYS2 MINGW64 or a cross-compiler) before submitting.\n\nIf a change touches code already covered by the GitHub CI workflow regression tests (`.github/workflows/`), run those tests locally and make sure they still pass before presenting the change.\n\n- `tools/ci_local.py which <changed files>` lists the jobs that name them (through a sample's Makefile or a tools/ script too), the full-tree builds and the tree-wide checks.\n- `tools/ci_local.py run <workflow> --job <job>` runs that job's own steps, with its configure line, flags, matrix and environment. `--dry-run` prints them, `--clean-copy` runs on a fresh worktree of HEAD plus your changes, and container jobs run in their image through docker or podman.\n- Do not present a change while any of those tests fail.\n- A workflow construct `ci_local.py` cannot read fails `tools/ci_local.py selftest`, which CI runs; extend the script in the same change.\n- A job's Ubuntu packages go in its `APT_PKGS` and are installed once, through `.github/workflows/scripts/apt-install.sh` and its cache steps; `tools/ci_apt_check.py` fails any other `apt-get` in a runner job.\n\n## Never commit build output\n\nNothing built is ever committed: no executables, objects, libraries,\narchives, generated images or captures. This includes every sample and\ntool harness built under samples/, libretro-common/samples/ and tools/.\n\n- Stage files by name (`git add path/file.c`), never a directory or\n  `git add -A`, so a build that ran after a `make clean` cannot slip in.\n- Before every commit run `git status --short` and check that each\n  staged path is source, a Makefile, a script or documentation.\n- A new harness whose executable name the `.gitignore` patterns do not\n  cover (`*_test`, `*_test_*`) gets its own ignore line in the same\n  commit that adds the harness.\n\n## Scope of changes\n\nKeep changes focused.\n\n### Do not:\n\n- reformat unrelated code;\n- rename unrelated symbols;\n- modernize C89 code;\n- replace established patterns with preferred patterns;\n- refactor neighboring code without a direct need;\n- add documentation or comments solely to explain the current change;\n- make speculative improvements.\n\nIf a task requires a broad change, make the breadth necessary for the feature rather than artificially minimizing the number of files changed.\n\nA change touching many files is not inherently a problem in RetroArch. Missing a required layer of an established multi-file system is a problem.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"AGENTS.md\n\n## Project\n\nRetroArch is primarily written in C89. Preserve the existing language and style of the file being edited.\n\n- New C code must be C89-compatible unless the surrounding code explicitly requires otherwise.\n- Do not introduce C99/C11 features into C89 code.\n- Existing files written in C++, Objective-C, or another language should remain in that language.\n- Follow the conventions of surrounding code rather than introducing a new style.\n- Prefer the smallest change that completely solves the task.\n- Preserve existing architecture\n\nRead CODING-GUIDELINES before changing code: brace style, declarations,\nstack budgets and the never-block rule for the main thread are there.\nSubdirectories with rules of their own carry their own AGENTS.md.\n`tools/compile_commands.py`, after ./configure, writes compile_commands.json\nfor clangd and other code navigation.\n\n## Threads\n\n- Nothing may block: no sleeping, busy-waiting, wait-for-idle or round-trip\n  waits, least of all in the threaded video wrapper and the audio pipeline.\n  A design that needs to block is shaped wrong.\n- Do not add locks. Use retro_atomic.h, the SPSC rings (retro_spsc.h,\n  retro_waitable_spsc.h) and retro_eventcount.h.\n- Guard threaded code with HAVE_THREADS, and check it with a full\n  `./configure --disable-threads` build that links, not a single TU.\n- No logging inside pacing or sync paths.\n\nRetroArch contains deliberately complex, cross-file systems. Do not simplify, consolidate, refactor, or redesign an existing subsystem merely because its structure appears unnecessarily complicated.\n\nComplexity may exist for compatibility, platform, driver, or architectural reasons.\n\nWhen implementing a feature, find an existing feature with similar behavior and follow its implementation pattern. The current source tree takes precedence over historical examples.\n\nDo not make unrelated cleanup or refactoring changes.\n\n## Comments\n\nKeep comments as short as possible.\n\n- Prefer no comment when the code is self-explanatory.\n- When a comment is necessary, prefer a few words or a few lines at most.\n- Explain why something is non-obvious, rather than describing what obvious code does.\n- Do not add comments merely because code was changed.\n- Do not describe the previous implementation or behavior unless that historical context is necessary to understand the current code.\n- Do not use comments as miniature documentation or change logs.\n- Prefer clear names and straightforward code over explanatory comments.\n\nComments should describe information that will remain useful after the current change is forgotten.\n\n## Commit messages\n\nKeep commit messages concise and focused.\n\n- Explain what changed and why.\n- Prefer a short subject line and a brief body when additional context is useful.\n- Do not enumerate every changed file or implementation detail.\n- Do not describe intermediate attempts, discarded approaches, or the development process.\n- Do not explain the previous implementation unless it is necessary to understand the change.\n- Keep the complete commit message below approximately 600 words.\n- A commit message is not a changelog or development diary.\n\n## Menu changes\n\nAdding or modifying a menu option commonly requires changes in several parts of the codebase.\n\nDo not assume that a menu option can be implemented by modifying only the file where it is displayed.\n\n### Before adding a menu option:\n\n- Find an existing menu option with similar behavior.\n- Trace its complete implementation through the menu, settings, configuration, and message systems.\n- Identify every part of that pattern that applies to the new option.\n- Implement the new option consistently across all required layers.\n- Do not modify unrelated menu code.\n\n#### Useful reference commits:\n\n- 6e9aa66aea2b2b3d0687585e41bac658ac9ae252 — SMB timeout/context settings exposed as menu options.\n- 434f41b935232325ed13024786653f9dfef49643 — CRT menu additions.\n- 23170b82ec58c2b283a7132b85fa73e18050a5ae — MIDI device dropdown menu items.\n05faba73e3fed69a5e118df2cc28d31309089243 — menu implementation example.\n\nThese are reference implementations, not fixed lists of files to modify. The required files depend on the feature.\n\n## Shader and video backend changes\n\nShader functionality frequently crosses shared shader code and multiple video backends.\n\n### When adding or modifying shader functionality:\n\n- Find an existing shader feature with similar behavior.\n- Trace the feature through the shared shader infrastructure.\n- Identify every applicable shader implementation and video backend.\n- Keep backend implementations consistent where the feature is supported.\n- Do not update only the backend currently being tested if the feature is expected to work elsewhere.\n- Check platform/backend-specific differences rather than blindly duplicating code.\n\n#### Useful reference commits:\n\n- da5ecaa45a862e51783eca1280f46fbfb7984ede — OriginalAspect and OriginalAspectRot uniforms.\n- 2a56a827e8a97a3838a9d455f1dca442c0ffbb07 — frametime/original-FPS shader uniforms.\n- 37cfa4857d064464754e800bad89ce69e81230fe — sensor shader uniforms across multiple shader and video/input backends.\n\nThese commits demonstrate the breadth of changes that may be required. They are examples of implementation patterns, not instructions to reproduce their exact file lists.\n\n## Historical commits\n\nHistorical commits may be used to understand established implementation patterns.\n\n- Treat examples as references, not specifications.\n- Prefer the current source tree when it differs from an historical commit.\n- Do not copy historical changes mechanically.\n- Do not reproduce obsolete workarounds merely because they appear in an old commit.\n- Inspect surrounding current code before applying a historical pattern.\n\n## Regression tests\n\nRegression tests must build on both Windows and Linux.\n\n- Do not use POSIX-only or Win32-only headers or APIs in test code without a working path for the other platform; prefer libretro-common facilities.\n- Check that the test builds with a Linux toolchain and with mingw-w64 (MSYS2 MINGW64 or a cross-compiler) before submitting.\n\nIf a change touches code already covered by the GitHub CI workflow regression tests (`.github/workflows/`), run those tests locally and make sure they still pass before presenting the change.\n\n- `tools/ci_local.py which <changed files>` lists the jobs that name them (through a sample's Makefile or a tools/ script too), the full-tree builds and the tree-wide checks.\n- `tools/ci_local.py run <workflow> --job <job>` runs that job's own steps, with its configure line, flags, matrix and environment. `--dry-run` prints them, `--clean-copy` runs on a fresh worktree of HEAD plus your changes, and container jobs run in their image through docker or podman.\n- Do not present a change while any of those tests fail.\n- A workflow construct `ci_local.py` cannot read fails `tools/ci_local.py selftest`, which CI runs; extend the script in the same change.\n- A job's Ubuntu packages go in its `APT_PKGS` and are installed once, through `.github/workflows/scripts/apt-install.sh` and its cache steps; `tools/ci_apt_check.py` fails any other `apt-get` in a runner job.\n\n## Never commit build output\n\nNothing built is ever committed: no executables, objects, libraries,\narchives, generated images or captures. This includes every sample and\ntool harness built under samples/, libretro-common/samples/ and tools/.\n\n- Stage files by name (`git add path/file.c`), never a directory or\n  `git add -A`, so a build that ran after a `make clean` cannot slip in.\n- Before every commit run `git status --short` and check that each\n  staged path is source, a Makefile, a script or documentation.\n- A new harness whose executable name the `.gitignore` patterns do not\n  cover (`*_test`, `*_test_*`) gets its own ignore line in the same\n  commit that adds the harness.\n\n## Scope of changes\n\nKeep changes focused.\n\n### Do not:\n\n- reformat unrelated code;\n- rename unrelated symbols;\n- modernize C89 code;\n- replace established patterns with preferred patterns;\n- refactor neighboring code without a direct need;\n- add documentation or comments solely to explain the current change;\n- make speculative improvements.\n\nIf a task requires a broad change, make the breadth necessary for the feature rather than artificially minimizing the number of files changed.\n\nA change touching many files is not inherently a problem in RetroArch. Missing a required layer of an established multi-file system is a problem.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/libretro/RetroArch/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"AGENTS.md\n\n## Project\n\nRetroArch is primarily written in C89. Preserve the existing language and style of the file being edited.\n\n- New C code must be C89-compatible unless the surrounding code explicitly requires otherwise.\n- Do not introduce C99/C11 features into C89 code.\n- Existing files written in C++, Objective-C, or another language should remain in that language.\n- Follow the conventions of surrounding code rather than introducing a new style.\n- Prefer the smallest change that completely solves the task.\n- Preserve existing architecture\n\nRead CODING-GUIDELINES before changing code: brace style, declarations,\nstack budgets and the never-block rule for the main thread are there.\nSubdirectories with rules of their own carry their own AGENTS.md.\n`tools/compile_commands.py`, after ./configure, writes compile_commands.json\nfor clangd and other code navigation.\n\n## Threads\n\n- Nothing may block: no sleeping, busy-waiting, wait-for-idle or round-trip\n  waits, least of all in the threaded video wrapper and the audio pipeline.\n  A design that needs to block is shaped wrong.\n- Do not add locks. Use retro_atomic.h, the SPSC rings (retro_spsc.h,\n  retro_waitable_spsc.h) and retro_eventcount.h.\n- Guard threaded code with HAVE_THREADS, and check it with a full\n  `./configure --disable-threads` build that links, not a single TU.\n- No logging inside pacing or sync paths.\n\nRetroArch contains deliberately complex, cross-file systems. Do not simplify, consolidate, refactor, or redesign an existing subsystem merely because its structure appears unnecessarily complicated.\n\nComplexity may exist for compatibility, platform, driver, or architectural reasons.\n\nWhen implementing a feature, find an existing feature with similar behavior and follow its implementation pattern. The current source tree takes precedence over historical examples.\n\nDo not make unrelated cleanup or refactoring changes.\n\n## Comments\n\nKeep comments as short as possible.\n\n- Prefer no comment when the code is self-explanatory.\n- When a comment is necessary, prefer a few words or a few lines at most.\n- Explain why something is non-obvious, rather than describing what obvious code does.\n- Do not add comments merely because code was changed.\n- Do not describe the previous implementation or behavior unless that historical context is necessary to understand the current code.\n- Do not use comments as miniature documentation or change logs.\n- Prefer clear names and straightforward code over explanatory comments.\n\nComments should describe information that will remain useful after the current change is forgotten.\n\n## Commit messages\n\nKeep commit messages concise and focused.\n\n- Explain what changed and why.\n- Prefer a short subject line and a brief body when additional context is useful.\n- Do not enumerate every changed file or implementation detail.\n- Do not describe intermediate attempts, discarded approaches, or the development process.\n- Do not explain the previous implementation unless it is necessary to understand the change.\n- Keep the complete commit message below approximately 600 words.\n- A commit message is not a changelog or development diary.\n\n## Menu changes\n\nAdding or modifying a menu option commonly requires changes in several parts of the codebase.\n\nDo not assume that a menu option can be implemented by modifying only the file where it is displayed.\n\n### Before adding a menu option:\n\n- Find an existing menu option with similar behavior.\n- Trace its complete implementation through the menu, settings, configuration, and message systems.\n- Identify every part of that pattern that applies to the new option.\n- Implement the new option consistently across all required layers.\n- Do not modify unrelated menu code.\n\n#### Useful reference commits:\n\n- 6e9aa66aea2b2b3d0687585e41bac658ac9ae252 — SMB timeout/context settings exposed as menu options.\n- 434f41b935232325ed13024786653f9dfef49643 — CRT menu additions.\n- 23170b82ec58c2b283a7132b85fa73e18050a5ae — MIDI device dropdown menu items.\n05faba73e3fed69a5e118df2cc28d31309089243 — menu implementation example.\n\nThese are reference implementations, not fixed lists of files to modify. The required files depend on the feature.\n\n## Shader and video backend changes\n\nShader functionality frequently crosses shared shader code and multiple video backends.\n\n### When adding or modifying shader functionality:\n\n- Find an existing shader feature with similar behavior.\n- Trace the feature through the shared shader infrastructure.\n- Identify every applicable shader implementation and video backend.\n- Keep backend implementations consistent where the feature is supported.\n- Do not update only the backend currently being tested if the feature is expected to work elsewhere.\n- Check platform/backend-specific differences rather than blindly duplicating code.\n\n#### Useful reference commits:\n\n- da5ecaa45a862e51783eca1280f46fbfb7984ede — OriginalAspect and OriginalAspectRot uniforms.\n- 2a56a827e8a97a3838a9d455f1dca442c0ffbb07 — frametime/original-FPS shader uniforms.\n- 37cfa4857d064464754e800bad89ce69e81230fe — sensor shader uniforms across multiple shader and video/input backends.\n\nThese commits demonstrate the breadth of changes that may be required. They are examples of implementation patterns, not instructions to reproduce their exact file lists.\n\n## Historical commits\n\nHistorical commits may be used to understand established implementation patterns.\n\n- Treat examples as references, not specifications.\n- Prefer the current source tree when it differs from an historical commit.\n- Do not copy historical changes mechanically.\n- Do not reproduce obsolete workarounds merely because they appear in an old commit.\n- Inspect surrounding current code before applying a historical pattern.\n\n## Regression tests\n\nRegression tests must build on both Windows and Linux.\n\n- Do not use POSIX-only or Win32-only headers or APIs in test code without a working path for the other platform; prefer libretro-common facilities.\n- Check that the test builds with a Linux toolchain and with mingw-w64 (MSYS2 MINGW64 or a cross-compiler) before submitting.\n\nIf a change touches code already covered by the GitHub CI workflow regression tests (`.github/workflows/`), run those tests locally and make sure they still pass before presenting the change.\n\n- `tools/ci_local.py which <changed files>` lists the jobs that name them (through a sample's Makefile or a tools/ script too), the full-tree builds and the tree-wide checks.\n- `tools/ci_local.py run <workflow> --job <job>` runs that job's own steps, with its configure line, flags, matrix and environment. `--dry-run` prints them, `--clean-copy` runs on a fresh worktree of HEAD plus your changes, and container jobs run in their image through docker or podman.\n- Do not present a change while any of those tests fail.\n- A workflow construct `ci_local.py` cannot read fails `tools/ci_local.py selftest`, which CI runs; extend the script in the same change.\n- A job's Ubuntu packages go in its `APT_PKGS` and are installed once, through `.github/workflows/scripts/apt-install.sh` and its cache steps; `tools/ci_apt_check.py` fails any other `apt-get` in a runner job.\n\n## Never commit build output\n\nNothing built is ever committed: no executables, objects, libraries,\narchives, generated images or captures. This includes every sample and\ntool harness built under samples/, libretro-common/samples/ and tools/.\n\n- Stage files by name (`git add path/file.c`), never a directory or\n  `git add -A`, so a build that ran after a `make clean` cannot slip in.\n- Before every commit run `git status --short` and check that each\n  staged path is source, a Makefile, a script or documentation.\n- A new harness whose executable name the `.gitignore` patterns do not\n  cover (`*_test`, `*_test_*`) gets its own ignore line in the same\n  commit that adds the harness.\n\n## Scope of changes\n\nKeep changes focused.\n\n### Do not:\n\n- reformat unrelated code;\n- rename unrelated symbols;\n- modernize C89 code;\n- replace established patterns with preferred patterns;\n- refactor neighboring code without a direct need;\n- add documentation or comments solely to explain the current change;\n- make speculative improvements.\n\nIf a task requires a broad change, make the breadth necessary for the feature rather than artificially minimizing the number of files changed.\n\nA change touching many files is not inherently a problem in RetroArch. Missing a required layer of an established multi-file system is a problem.\n","isInternal":false,"tokens":1797,"sizeBytes":8515},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":197},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":183},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":176}],"systemPromptSnippet":"<yakaai_skills repo=\"libretro/RetroArch\">\n<!-- File: AGENTS.md (Tokens: ~1797 | Category: root-instruction) -->\nAGENTS.md\n\n## Project\n\nRetroArch is primarily written in C89. Preserve the existing language and style of the file being edited.\n\n- New C code must be C89-compatible unless the surrounding code explicitly requires otherwise.\n- Do not introduce C99/C11 features into C89 code.\n- Existing files written in C++, Objective-C, or another language should remain in that language.\n- Follow the conventions of surrounding code rather than introducing a new style.\n- Prefer the smallest change that completely solves the task.\n- Preserve existing architecture\n\nRead CODING-GUIDELINES before changing code: brace style, declarations,\nstack budgets and the never-block rule for the main thread are there.\nSubdirectories with rules of their own carry their own AGENTS.md.\n`tools/compile_commands.py`, after ./configure, writes compile_commands.json\nfor clangd and other code navigation.\n\n## Threads\n\n- Nothing may block: no sleeping, busy-waiting, wait-for-idle or round-trip\n  waits, least of all in the threaded video wrapper and the audio pipeline.\n  A design that needs to block is shaped wrong.\n- Do not add locks. Use retro_atomic.h, the SPSC rings (retro_spsc.h,\n  retro_waitable_spsc.h) and retro_eventcount.h.\n- Guard threaded code with HAVE_THREADS, and check it with a full\n  `./configure --disable-threads` build that links, not a single TU.\n- No logging inside pacing or sync paths.\n\nRetroArch contains deliberately complex, cross-file systems. Do not simplify, consolidate, refactor, or redesign an existing subsystem merely because its structure appears unnecessarily complicated.\n\nComplexity may exist for compatibility, platform, driver, or architectural reasons.\n\nWhen implementing a feature, find an existing feature with similar behavior and follow its implementation pattern. The current source tree takes precedence over historical examples.\n\nDo not make unrelated cleanup or refactoring changes.\n\n## Comments\n\nKeep comments as short as possible.\n\n- Prefer no comment when the code is self-explanatory.\n- When a comment is necessary, prefer a few words or a few lines at most.\n- Explain why something is non-obvious, rather than describing what obvious code does.\n- Do not add comments merely because code was changed.\n- Do not describe the previous implementation or behavior unless that historical context is necessary to understand the current code.\n- Do not use comments as miniature documentation or change logs.\n- Prefer clear names and straightforward code over explanatory comments.\n\nComments should describe information that will remain useful after the current change is forgotten.\n\n## Commit messages\n\nKeep commit messages concise and focused.\n\n- Explain what changed and why.\n- Prefer a short subject line and a brief body when additional context is useful.\n- Do not enumerate every changed file or implementation detail.\n- Do not describe intermediate attempts, discarded approaches, or the development process.\n- Do not explain the previous implementation unless it is necessary to understand the change.\n- Keep the complete commit message below approximately 600 words.\n- A commit message is not a changelog or development diary.\n\n## Menu changes\n\nAdding or modifying a menu option commonly requires changes in several parts of the codebase.\n\nDo not assume that a menu option can be implemented by modifying only the file where it is displayed.\n\n### Before adding a menu option:\n\n- Find an existing menu option with similar behavior.\n- Trace its complete implementation through the menu, settings, configuration, and message systems.\n- Identify every part of that pattern that applies to the new option.\n- Implement the new option consistently across all required layers.\n- Do not modify unrelated menu code.\n\n#### Useful reference commits:\n\n- 6e9aa66aea2b2b3d0687585e41bac658ac9ae252 — SMB timeout/context settings exposed as menu options.\n- 434f41b935232325ed13024786653f9dfef49643 — CRT menu additions.\n- 23170b82ec58c2b283a7132b85fa73e18050a5ae — MIDI device dropdown menu items.\n05faba73e3fed69a5e118df2cc28d31309089243 — menu implementation example.\n\nThese are reference implementations, not fixed lists of files to modify. The required files depend on the feature.\n\n## Shader and video backend changes\n\nShader functionality frequently crosses shared shader code and multiple video backends.\n\n### When adding or modifying shader functionality:\n\n- Find an existing shader feature with similar behavior.\n- Trace the feature through the shared shader infrastructure.\n- Identify every applicable shader implementation and video backend.\n- Keep backend implementations consistent where the feature is supported.\n- Do not update only the backend currently being tested if the feature is expected to work elsewhere.\n- Check platform/backend-specific differences rather than blindly duplicating code.\n\n#### Useful reference commits:\n\n- da5ecaa45a862e51783eca1280f46fbfb7984ede — OriginalAspect and OriginalAspectRot uniforms.\n- 2a56a827e8a97a3838a9d455f1dca442c0ffbb07 — frametime/original-FPS shader uniforms.\n- 37cfa4857d064464754e800bad89ce69e81230fe — sensor shader uniforms across multiple shader and video/input backends.\n\nThese commits demonstrate the breadth of changes that may be required. They are examples of implementation patterns, not instructions to reproduce their exact file lists.\n\n## Historical commits\n\nHistorical commits may be used to understand established implementation patterns.\n\n- Treat examples as references, not specifications.\n- Prefer the current source tree when it differs from an historical commit.\n- Do not copy historical changes mechanically.\n- Do not reproduce obsolete workarounds merely because they appear in an old commit.\n- Inspect surrounding current code before applying a historical pattern.\n\n## Regression tests\n\nRegression tests must build on both Windows and Linux.\n\n- Do not use POSIX-only or Win32-only headers or APIs in test code without a working path for the other platform; prefer libretro-common facilities.\n- Check that the test builds with a Linux toolchain and with mingw-w64 (MSYS2 MINGW64 or a cross-compiler) before submitting.\n\nIf a change touches code already covered by the GitHub CI workflow regression tests (`.github/workflows/`), run those tests locally and make sure they still pass before presenting the change.\n\n- `tools/ci_local.py which <changed files>` lists the jobs that name them (through a sample's Makefile or a tools/ script too), the full-tree builds and the tree-wide checks.\n- `tools/ci_local.py run <workflow> --job <job>` runs that job's own steps, with its configure line, flags, matrix and environment. `--dry-run` prints them, `--clean-copy` runs on a fresh worktree of HEAD plus your changes, and container jobs run in their image through docker or podman.\n- Do not present a change while any of those tests fail.\n- A workflow construct `ci_local.py` cannot read fails `tools/ci_local.py selftest`, which CI runs; extend the script in the same change.\n- A job's Ubuntu packages go in its `APT_PKGS` and are installed once, through `.github/workflows/scripts/apt-install.sh` and its cache steps; `tools/ci_apt_check.py` fails any other `apt-get` in a runner job.\n\n## Never commit build output\n\nNothing built is ever committed: no executables, objects, libraries,\narchives, generated images or captures. This includes every sample and\ntool harness built under samples/, libretro-common/samples/ and tools/.\n\n- Stage files by name (`git add path/file.c`), never a directory or\n  `git add -A`, so a build that ran after a `make clean` cannot slip in.\n- Before every commit run `git status --short` and check that each\n  staged path is source, a Makefile, a script or documentation.\n- A new harness whose executable name the `.gitignore` patterns do not\n  cover (`*_test`, `*_test_*`) gets its own ignore line in the same\n  commit that adds the harness.\n\n## Scope of changes\n\nKeep changes focused.\n\n### Do not:\n\n- reformat unrelated code;\n- rename unrelated symbols;\n- modernize C89 code;\n- replace established patterns with preferred patterns;\n- refactor neighboring code without a direct need;\n- add documentation or comments solely to explain the current change;\n- make speculative improvements.\n\nIf a task requires a broad change, make the breadth necessary for the feature rather than artificially minimizing the number of files changed.\n\nA change touching many files is not inherently a problem in RetroArch. Missing a required layer of an established multi-file system is a problem.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/libretro/RetroArch/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}