agentleFS
Farama-FoundationFarama-Foundation/stable-retro/.github/skills/add-emulator-platform/SKILL.md

add-emulator-platform

Skill1.1k starsChanged 3 months agoMITView on GitHub

Add or review a new emulator platform, game system, libretro core, ROM extension mapping, or core build target in Stable Retro. Use for platform ports and core integrations, not ordinary game integrations.

Trending

Quiet since August.thin dataabout the whole repository

Dec 2025: 1 mentionJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 1 mentionMay 2026: 0 mentionsJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 1 mentionSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the Farama-Foundation/stable-retro repository that our weekly crawl found: only 10 in all, so this is a hint, not a trend. There is no adoption data for this file yet.

Who's talking about Farama-Foundation/stable-retro

The biggest 5 of 10 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 10

Talked about on GitHub (10 times).

On GitHub · 10

5 more on GitHub

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 2 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this workflow for a new emulated system or libretro core.

    line 8
  2. Very specific:

    Ensure the core's Makefile produces <core_name>_libretro with the host shared-library suffix.

    line 26
  3. Very specific:

    Keep buttons and keybinds aligned to libretro joypad IDs.

    line 28
  4. Very specific:

    Add add_core(<platform> <core_name>) in CMakeLists.txt.

    line 35
  5. Very specific:

    Add only required deterministic core options to s_envVariables in src/emulator.cpp.

    line 36
  6. Very specific:

    Add the platform suffix to setup.py only when packaged game integrations use that suffix.

    line 37
  7. Very specific:

    Update tests/emulator.cpp with manifest loading and an emulator smoke parameter when a redistributable fixture exists.

    line 38
  8. Very specific:

    Update docs/supported_emulators.md and, when users can import games for the system, the supported ROM types in docs/integration.md.

    line 39
  9. Distinctive:

    Run relevant Python tests and repository checks:

    line 56
  10. Distinctive:

    Use the completion checklist before finishing.

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Add an Emulator Platform

Use this workflow for a new emulated system or libretro core. A game integration only adds data under stable_retro/data/ and should follow docs/integration.md instead.

Gather requirements

Before editing, establish:

  • Stable Retro platform identifier and game-directory suffix.
  • Core directory slug and expected libretro library basename.
  • Upstream repository, pinned revision, license, and redistribution terms.
  • ROM extensions, libretro joypad layout, RAM regions, serialization behavior, and BIOS needs.
  • Supported host matrix: Linux, Windows, macOS x86_64, and macOS arm64.
  • A legally redistributable smoke-test ROM, or a documented manual-test substitute.

Compare one nearby simple platform manifest and one platform with similar rendering, BIOS, or architecture constraints. Do not assume a core's standalone defaults are suitable for deterministic, headless reinforcement learning.

Implement the platform

  1. Vendor the pinned core under cores/<platform>/. Preserve upstream licensing and avoid unrelated source edits.
  2. Ensure the core's Makefile produces <core_name>_libretro with the host shared-library suffix. The top-level add_core function expects this exact name.
  3. Copy the manifest template to cores/<platform>.json and adapt it. The top-level key is the public platform identifier; lib is <core_name> from CMake.
  4. Keep buttons and keybinds aligned to libretro joypad IDs. Use null for unsupported positions and list only valid button names in actions.
  5. Validate the manifest before compiling:

    python .github/skills/add-emulator-platform/scripts/validate_manifest.py cores/<platform>.json
  6. Add add_core(<platform> <core_name>) in CMakeLists.txt. Guard it when host support or system libraries are conditional.
  7. Add only required deterministic core options to s_envVariables in src/emulator.cpp. Prefer software rendering unless the core truly requires ENABLE_HW_RENDER.
  8. Add the platform suffix to setup.py only when packaged game integrations use that suffix. Core JSON and shared-library packaging is already generic.
  9. Update tests/emulator.cpp with manifest loading and an emulator smoke parameter when a redistributable fixture exists. Otherwise add lower-level mapping coverage and record manual load, frame, audio, reset, and serialization evidence.
  10. Update docs/supported_emulators.md and, when users can import games for the system, the supported ROM types in docs/integration.md.

Validate incrementally

Build the new core first:

cmake -DCMAKE_DISABLE_FIND_PACKAGE_CapnProto=TRUE .
cmake --build . --target <platform> -- -j2

Then run the native suite:

CMAKE_BUILD_PARALLEL_LEVEL=2 scripts/test-cpp.sh

Run relevant Python tests and repository checks:

scripts/test-python.sh
python -m pre_commit run --files <changed-files>

Use the completion checklist before finishing. Clearly report any host platform or hardware path that was not tested.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.