Nintendo Switch decomp guide

What this system is like

Switch games run on a 64-bit ARM chip. Since October 2026, more than a dozen games got native PC builds. Every project we read used static recompilation. That means a tool turns the game's machine code into C, and you write a stand-in for the console around it.

You do not start from zero. Most of the projects we read copied an older Switch recomp and changed only the game parts. Your first job is to pick that base. Then you strip out the old game's patches and fix what breaks.

The hard parts are the same each time. The game expects Nintendo's own system and its own graphics API, called NVN. Its shaders are machine code for an NVIDIA chip. They must be turned into Vulkan shaders.

A full decomp is a different story. No Switch game is fully decompiled yet. The oldest large project, for Breath of the Wild, is about 21% done after six years. Plan Path B as a long project, and be ready to accept code that does not match byte for byte.

Two paths

Path A: Get it running on PC

A Python lifter reads each NSO module and writes one C function per game function. A runtime stands in for Horizon, its services, audio, input and NVN. NVN calls go to Vulkan, and shaders are translated to SPIR-V. A Unicorn test checks that the lifter translates each ARM instruction correctly. You build on the player's PC from their own dump.

1. Pick the game, the version and a base

   You choose one exact game version and one recomp to fork. You check that the game is 64-bit. You look for a sister project on the same engine. You write it all in SCOPE.md.

   • Dump your own game and update. Keep the files outside the repo, for example in D:/dumps/<game>.
   • Read the Is64BitInstruction bit in main.npdm. KirbyRecomp checks this first. Mario Kart 8 Deluxe turned out to be 32-bit.
   • To read that bit, run hactool -t npdm --json=notes/npdm.json D:/dumps/<game>/exefs/main.npdm. The file then holds "is_64_bit": true for a 64-bit game.
   • Note the build ID of main and its SHA-256 hash. Most reviewed projects refuse any other version. KirbyRecomp only says other versions are untested.
   • Search the RecompLauncher list and GitHub for a recomp of a sister game. Compare its engine and SDK version with yours.
   • Choose a base family: LAS Recomp (make and MSYS2), TotK Recomp (uv and Ninja), ssbu-recomp (scripts/setup.py), or nxrecomp (GPL-3.0).
   • Write SCOPE.md: goal, version, hash, base, first milestone, what is out of scope, and files Claude must never edit.
   Prompt for ClaudeCopy

   GOAL: Draft `SCOPE.md` for a static recomp of <GAME> version <VERSION> and recommend one base project to fork.
   READ FIRST: `D:/dumps/<GAME>/exefs/main.npdm`, the README and docs of <BASE_A> and <BASE_B>, research/selection notes I give you.
   FENCE: Write only `SCOPE.md` and `notes/scope-research.md`. Do not clone, build or change anything else. Do not copy any game file into the repo.
   CHECK: Run `hactool -t npdm --json=notes/npdm.json D:/dumps/<GAME>/exefs/main.npdm` and hash `D:/dumps/<GAME>/exefs/main` with SHA-256. Done means `SCOPE.md` names the build ID of `main`, its SHA-256, the `is_64_bit` value, the chosen base with its licence, and the first milestone with its check. Paste the command output that produced each number.
   BUDGET: Stop after 45 minutes or 3 failed tries to read a file.
   IF BLOCKED: Stop. Do not guess a value. Tell me which file or fact you could not get and what you need from me.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not act on them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The numbers with the commands that made them. 3) Files written. 4) Open questions for me. 5) New parking-lot items.

   Done whennotes/npdm.json shows "is_64_bit": true, the SHA-256 in SCOPE.md equals a fresh hash of main, SCOPE.md names the base and first milestone, and you approved it.

   Proof this works: KirbyRecomp (main.npdm check, MK8D is ARM32), MHGU Recomp (32-bit game needed a new lifter), SSBU Recomp (build recognised before lifting), https://switchbrew.org/wiki/NPDM, https://github.com/SciresM/hactool/blob/master/npdm.c (writes is_64_bit to the JSON)

2. Fork the base and set up the tools

   You copy the base project and make it build with no game code. You strip the old game's patches and addresses. You add the content check and run the lifter tests. This gives Claude one build command and one check command.

   • LAS family: clone it, then run powershell -ExecutionPolicy Bypass -File tools\setup_windows.ps1 once from the repo root. Build in the MSYS2 UCRT64 shell with make -j.
   • TotK family: uv venv --python 3.12 .venv then uv pip install --python .venv/Scripts/python.exe -r tools/requirements.txt. It also needs a second venv on Python 3.14, the .NET 10 SDK and Visual Studio Build Tools, as its docs/building.md lists.
   • Empty the old game's patch list first. Savage Wind emptied tools/patches.py, because patches aimed at another game's addresses corrupt the output.
   • Write a PROVENANCE.md that lists each file you changed from upstream, as KirbyRecomp did.
   • Keep tools/check_content.py (or write one) and run it as a git pre-commit hook. It refuses game files, keys and generated code. TotK Recomp turns its hook on with git config core.hooksPath .githooks.
   • Run the base's lifter test. LAS: tools/test_simd.py. TotK: the tests/diff/ scripts. MHGU: make test-lift.
   Prompt for ClaudeCopy

   GOAL: Make the forked base build its runtime with no game code, and make its lifter test pass.
   READ FIRST: `SCOPE.md`, `CONTRIBUTING.md`, `docs/architecture.md`, the base's build doc.
   FENCE: Edit only `tools/patches.py` (to empty it), `PROVENANCE.md`, `.githooks/`, `CLAUDE.md` and `notes/`. Do not touch the lifter, the runtime or `tools/vendor/`. Do not add features or refactors.
   CHECK: Run `<BUILD_COMMAND>` and `<LIFTER_TEST_COMMAND>`. Done means the build ends with no errors and the lifter test reports 0 mismatches. Also run `python tools/check_content.py --staged` and show it passes.
   BUDGET: Stop after 3 failed builds with the same error, or 60 minutes with no progress.
   IF BLOCKED: Stop. Do not work around a missing tool. Tell me the exact error, what you tried, and what you need me to install.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the last 20 lines of the build and the test summary. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe runtime builds with no game code, the lifter test reports 0 mismatches, and the content check passes.

   Proof this works: Savage Wind Recomp (emptied tools/patches.py first), KirbyRecomp (PROVENANCE.md), TotK Recomp (check_content.py as hook and CI), https://github.com/peiikai/LASRecomp

3. Survey the code before you lift

   You measure the game's code and compare it with the base game. You count modules, sizes, imports and the SDK version. The difference tells you what the runtime lacks before anything runs.

   • Have Claude write a probe script like Tera Recomp's tools/sv_analyze.py or Savage Wind's tools/sw_probe.py. It prints sizes and imports without writing C.
   • Count imported nn:: functions by namespace. Mark each one as handled by the base or missing.
   • Look for C++ exception tables, TLS (thread-local data) use and setjmp. Witch Time found exception tables and TLS were new to its base. Tera Recomp and Savage Wind had to add setjmp support.
   • Open main in Ghidra with the Switch loader to check odd spots. Commit only counts and build IDs, never code.
   • Save the ledger as notes/imports.csv with columns: name, module, status, owner.
   Prompt for ClaudeCopy

   GOAL: Produce `notes/imports.csv` and `notes/survey.md` that compare <GAME>'s ExeFS with the base game's.
   READ FIRST: `SCOPE.md`, `D:/dumps/<GAME>/exefs/` (read only), the base's list of handled imports in `<RUNTIME_IMPORT_TABLE>`.
   FENCE: Write only `tools/survey.py`, `notes/imports.csv` and `notes/survey.md`. The dump is read-only. Do not paste disassembly into any file.
   CHECK: Run `python tools/survey.py D:/dumps/<GAME>/exefs`. Done means every module is listed with size and build ID, every import has a status, and the totals in `notes/survey.md` add up.
   BUDGET: Stop after 90 minutes or 3 failed runs of the script.
   IF BLOCKED: Stop. Tell me which file could not be parsed and the exact error.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the script's summary lines. 3) Files written. 4) The top 10 missing imports by call count. 5) New parking-lot items.

   Done whennotes/imports.csv lists every import with a status, and notes/survey.md names the SDK version and new features the base lacks.

   Proof this works: Tera Recomp (tools/sv_analyze.py, docs/phase1-analysis.md; setjmp needed a runtime helper), Witch Time (docs/RE_NOTES.md: exception tables, TLS, 32 new NVN entry points), Savage Wind Recomp (tools/sw_probe.py; setjmp in sdk needed an HLE longjmp)

4. Lift and link the whole game

   You run the lifter over every module and link the result. You do not try to run it yet. You count what the lifter could not handle. The goal is zero unsupported instructions and a clean link.

   • LAS family: make gen once, then make -j.
   • TotK family: .venv/Scripts/python recomp/gen.py --exefs build/extracted/<ver>/exefs --out generated/<ver> --patches recomp/patches-<ver>.txt then .venv/Scripts/python tools/build_game.py --version <ver>. Your fork's patch file starts empty.
   • If memory runs out, lift with one worker. Tera Recomp used --jobs 1 for a 52 MiB main. TotK's gen.py also halves its workers by itself when one runs out of memory.
   • List unhandled instructions, traps and unresolved jump tables in notes/lift-report.md.
   • Fix each gap in the generator, never in generated/. Re-run the Unicorn test after each lifter change.
   Prompt for ClaudeCopy

   GOAL: Lift every module of <GAME> and link it, with 0 unsupported instructions.
   READ FIRST: `SCOPE.md`, `notes/survey.md`, `docs/architecture.md`, the lifter source in `recomp/`.
   FENCE: Edit only the lifter in `recomp/` and its tests. Never edit files in `generated/`. Do not touch the runtime.
   CHECK: Run `<LIFT_COMMAND>` then `<LINK_COMMAND>` then `<LIFTER_TEST_COMMAND>`. Done means the link succeeds, the lift log reports 0 unsupported instructions, and the lifter test reports 0 mismatches.
   BUDGET: One lifter gap per try. Stop after 3 failed tries on the same gap.
   IF BLOCKED: Stop. Name the instruction or pattern, its address in `main`, and what you tried.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix runtime issues here.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the lift summary and the test summary. 3) Files changed. 4) Gaps left, with counts. 5) New parking-lot items.

   Done whenThe game links, the lift log shows 0 unsupported instructions, and the Unicorn lifter test shows 0 mismatches.

   Proof this works: Tera Recomp (phase 2: lift and link before running), Witch Time (55,277 functions lifted in 5 s), TotK Recomp (gen.py and build_game.py steps)

5. Boot to the first frame

   You run the game and fix each stop on the way to the first picture. A strict mode prints every missing import by name. Each stop gets one row in a boot log. This is first light.

   • Add a strict mode that traps any call to an unhandled import and prints its name, like Witch Time's WT_STRICT=report.
   • Keep notes/boot-log.md as a table: Stop, Cause, Fix, file. Tera Recomp did this for each crash.
   • Add a scripted run with a scratch save folder and a screenshot at a set frame, like LAS Recomp's tools/shot.sh.
   • The TotK family already has one: .venv\Scripts\python tools\run_game.py build\<dir> --save <name> --seconds 30 --shot out.png. Add --script <input.txt> to replay input.
   • Use a crash-address tool like LAS Recomp's tools/sym.py to map a crash to main+0x....
   Prompt for ClaudeCopy

   GOAL: Get <GAME> to draw its first frame with no crash in a scripted run.
   READ FIRST: `SCOPE.md`, `notes/boot-log.md`, `notes/imports.csv`, `docs/architecture.md`.
   FENCE: Edit only `runtime/` and `notes/`. Never edit `generated/`. Do not add stubs that return success without a comment that names the cause.
   CHECK: Run `<SCRIPTED_RUN_COMMAND>` with a time limit and a screenshot at the end, for example `.venv\Scripts\python tools\run_game.py build\<DIR> --save <SAVE> --seconds 30 --shot notes/first-light.png`. Done means the run exits without a crash and the screenshot shows the game's first screen. Attach the screenshot path and the last 30 log lines.
   BUDGET: One stop per try. Stop after 3 failed fixes on the same stop, or 60 minutes with no new row in the boot log.
   IF BLOCKED: Stop. Give the crash address, the missing import or service, and what you tried.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Screenshot path and log lines. 3) Files changed. 4) New boot-log rows. 5) New parking-lot items.

   Done whenA scripted run shows the game's first screen in a saved screenshot and exits without a crash.

   Proof this works: Witch Time (strict mode, title at frame 600), Tera Recomp (docs/phase3-boot.md Stop/Cause/Fix table), LAS Recomp (tools/shot.sh, tools/sym.py), https://github.com/valentderah/totk-pc-recomp/blob/main/docs/agents/running.md (run_game.py flags)

6. Fix one crash or glitch at a time

   This is the grind. Each task is one crash, one missing service or one wrong picture. Claude must prove the cause before it changes code. Shader work gets its own offline count.

   • Dump every shader the game uses, then translate and validate all of them offline. Witch Time tracked this as a number: 7,838 of 7,838.
   • Run with Vulkan validation layers on. Treat any new message as a bug.
   • When static reading fails, compare with a working emulator run. Tera Recomp attached gdb to Ryujinx to find a missing object.
   • Write each finding as a numbered note with symptom, cause and fix, as FEFW Recomp did in docs/debug/NNN.md.
   • Write dead ends down too, so no session tries them again.
   Prompt for ClaudeCopy

   GOAL: Find and fix the cause of <BUG> (seen at <WHERE_IN_GAME>).
   READ FIRST: `SCOPE.md`, `notes/symptoms.md`, `notes/debug/`, the log at `<LOG_PATH>`.
   FENCE: Edit only `runtime/` and `notes/`. Never edit `generated/`. A stub, clamp, retry or longer timeout is allowed only if the cause is known and named in a comment.
   CHECK: First write the cause with evidence: the faulting address, the wrong value and who wrote it. Then run `<SCRIPTED_RUN_COMMAND>` before and after the fix. Done means the bug is gone in the after-run screenshot or log, and `<REGRESSION_COMMAND>` still passes.
   BUDGET: Stop after 2 refuted ideas or 90 minutes with no proven cause.
   IF BLOCKED: Stop. List what you checked, what each check ruled out, and what evidence you need.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Cause with evidence, and before and after proof. 3) Files changed. 4) A new `notes/debug/NNN.md` entry. 5) New parking-lot items.

   Done whenThe bug's cause is written with evidence, and a scripted run before and after shows it fixed with the regression set still passing.

   Proof this works: Witch Time (tools/mxcheck.c shader count), Tera Recomp (gdb on Ryujinx found the missing root node), FEFW Recomp (numbered debug notes), LAS Recomp (AGENTS.md: find why before changing code)

7. Build a regression set

   You make sure old fixes stay fixed. Scripted routes replay the same input. A deterministic mode can hash the game state each frame. Checks that need no game file can run in CI.

   • Record input routes from a fixed save, like B2 Recomp's tests/route_first_fight.txt.
   • If you can, add a deterministic mode that logs a state hash per frame. SSBU Recomp compares logs before and after a change. The first different line names the frame.
   • Add self-tests that need no game, like TotK Recomp's --selftest and --probe-* switches.
   • Run the synthetic lifter test in CI on every push, as SSBU Recomp and KirbyRecomp do.
   • Put each risky change behind a switch, and compare whole runs with it off and on.
   Prompt for ClaudeCopy

   GOAL: Add a regression command that replays <N> recorded routes and checks each one.
   READ FIRST: `SCOPE.md`, `notes/PROGRESS.md`, the scripted run tool `<RUN_TOOL>`.
   FENCE: Edit only `tests/`, `tools/regress.*` and `notes/`. Do not change game behavior in `runtime/`.
   CHECK: Run `<REGRESSION_COMMAND>` twice on the same build. Done means every route passes both times with the same result. Then break one known fix on a scratch branch and show the command fails.
   BUDGET: Stop after 3 failed tries to make a route stable.
   IF BLOCKED: Stop. Tell me which route is not repeatable and what changes between runs.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Output of both runs and of the broken run. 3) Files changed. 4) Routes still missing. 5) New parking-lot items.

   Done when<REGRESSION_COMMAND> passes twice in a row and fails when a known fix is removed.

   Proof this works: SSBU Recomp (deterministic state hash log), B2 Recomp (scripts/bench.py with A/B mode), TotK Recomp (--selftest and probes)

8. Package it without game code

   You make the build run on a player's PC from their own dump. The installer checks the dump's hashes first. The release holds no game code. You document known problems plainly.

   • Check the player's dump by SHA-256 or build ID before any work, and stop on a mismatch.
   • Bundle the generator and a compiler, as LAS Recomp does with PyInstaller and zig cc. KirbyRecomp pins ziglang from PyPI.
   • Make setup resumable, with named steps and a log per step, as B2 Recomp's scripts/setup.py does.
   • Stamp the built game library with an ID so a stale one never loads, as Savage Wind does.
   • Tell players that antivirus may remove the big unsigned game DLL.
   Prompt for ClaudeCopy

   GOAL: Make a release that builds <GAME> on a clean PC from the player's own dump.
   READ FIRST: `SCOPE.md`, `docs/building.md`, `tools/check_content.py`.
   FENCE: Edit only `installer/`, `tools/make_release.*`, `docs/` and `notes/`. Do not change the lifter or runtime.
   CHECK: On a clean checkout, run `<RELEASE_COMMAND>`, then run the installer against `D:/dumps/<GAME>`. Done means the game reaches the title in a scripted run, a wrong dump is refused with a clear message, and `python tools/check_content.py` finds no game content in the release folder.
   BUDGET: Stop after 3 failed release builds.
   IF BLOCKED: Stop. Paste the failing step's log.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Proof for all three checks. 3) Files changed. 4) Known issues for the README. 5) New parking-lot items.

   Done whenA clean checkout builds a release, and the installer refuses a wrong dump. The game reaches the title. The content check passes on the release folder.

   Proof this works: LAS Recomp (frozen generator and zig cc), B2 Recomp (ten resumable setup steps), Savage Wind Recomp (GAMELIB_ID), Metroid Dread Recomp (RomFS manifest check)

Path B: Full decomp for porting

You write C++ that a public Clang compiles to the same bytes as the game. A tool called tools/check compares each function. Small functions often match. Big ones may never match, because Nintendo's compiler is private. For those, you keep readable code and test it against the running recomp.

1. Check prior work and pick the compiler

   You look for an existing decomp of your game or its engine. You find which SDK version built the game. The SDK version tells you which public Clang is closest. You decide what counts as done.

   • Check zeldaret/botw, MonsterDruide1/OdysseyDecomp and sbergeron42/ssbu-decomp for shared code such as sead or SDK parts.
   • Find the SDK version from the ExeFS, as Tera Recomp's survey script did.
   • Match the SDK to a Clang version. ssbu-decomp uses upstream LLVM 8.0.0 for SDK 8.2.1. The BotW decomp fetches Clang 4.0.1.
   • Write in SCOPE.md that big functions may stay non-matching, and how they will be tested instead.
   Prompt for ClaudeCopy

   GOAL: Draft the Path B part of `SCOPE.md` for <GAME> <VERSION>: prior work, SDK version, compiler choice and the meaning of done.
   READ FIRST: `SCOPE.md`, the READMEs of zeldaret/botw, MonsterDruide1/OdysseyDecomp and sbergeron42/ssbu-decomp, `D:/dumps/<GAME>/exefs/sdk` (read only).
   FENCE: Write only `SCOPE.md` and `notes/decomp-scope.md`. Do not set up a build yet.
   CHECK: Run `python tools/survey.py D:/dumps/<GAME>/exefs` and paste the SDK version line. Done means the draft names that SDK version, the chosen Clang version with a source, any shared library code already decompiled elsewhere, and the rule for non-matching functions.
   BUDGET: Stop after 60 minutes.
   IF BLOCKED: Stop. Say which fact you could not confirm. Do not guess a compiler version.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Each fact with its source. 3) Files written. 4) Open questions. 5) New parking-lot items.

   Done whenSCOPE.md names the SDK version, the Clang version with its source, prior work to reuse, and the non-matching rule, and you approved it.

   Proof this works: https://github.com/sbergeron42/ssbu-decomp, https://botw.link/contribute/installation, Tera Recomp (SDK version from ExeFS survey)

2. Set up the matching build in WSL

   You copy the layout the BotW and Odyssey decomps use. It has CMake, Ninja, a pinned Clang and the nx-decomp-tools checker. The build must work with an empty source tree. Then Claude has one build and one check command.

   • In WSL: sudo apt install python3 ninja-build cmake ccache xdelta3 clang libssl-dev pkg-config. BotW needs Python 3.12 or newer.
   • BotW needs CMake 3.30 or newer. Ubuntu 24.04 ships an older one, so also run pip install cmake (or use CMake's own APT repository).
   • Install Rust with curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh. BotW's setup builds some of its tools from Rust code.
   • Clone the repo inside WSL, not under /mnt/c. Building from the Windows side is much slower.
   • Add nx-decomp-tools as a submodule, then run git submodule update --init --recursive.
   • Write tools/setup.py <path to main> like BotW's. It sets up the venv, the checker, the converted main and the pinned Clang.
   • Build with ninja -C build, then run tools/check. It should print OK.
   Prompt for ClaudeCopy

   GOAL: Make an empty decomp project for <GAME> that builds and passes `tools/check`.
   READ FIRST: `SCOPE.md`, the BotW decomp's `tools/setup.py` and `CMakeLists.txt` as a pattern, `notes/decomp-scope.md`.
   FENCE: Edit only `CMakeLists.txt`, `tools/setup.py`, `toolchain/`, `.gitmodules` and `notes/`. Keep `main` and every dumped file outside the repo or in an ignored folder.
   CHECK: Run `tools/setup.py <MAIN_PATH>`, `ninja -C build` and `tools/check`. Done means the build has no errors and `tools/check` prints `OK`.
   BUDGET: Stop after 3 failed setup runs with the same error.
   IF BLOCKED: Stop. Paste the error and say which tool or version is missing.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the output of all three commands. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenninja -C build succeeds and tools/check prints OK on a fresh WSL clone.

   Proof this works: https://botw.link/contribute/installation, https://github.com/MonsterDruide1/OdysseyDecomp, https://github.com/open-ead/nx-decomp-tools

3. Build the function list

   You list every function with its address, size, status and name. Library code is marked so nobody decompiles it by hand. Names come from real evidence only. This file is the ledger for all later work.

   • Load main in Ghidra with the Switch loader. Export a CSV with the columns Address,Quality,Size,Name, like BotW's data/uking_functions.csv.
   • Take names from the binary's exported symbols first. ssbu-decomp calls these ground truth.
   • Mark known library code, such as sead, NintendoSDK, zstd or Lua, so workers skip it.
   • Sort functions by size. Small ones match most often with public Clang.
   Prompt for ClaudeCopy

   GOAL: Create `data/functions.csv` for <GAME> with every function's address, quality, size and name.
   READ FIRST: `SCOPE.md`, the Ghidra project at `<GHIDRA_PROJECT>`, BotW's `data/uking_functions.csv` header as a format example.
   FENCE: Write only `tools/export_functions.py`, `data/functions.csv` and `notes/map.md`. Do not rename anything without a source. No disassembly in any committed file.
   CHECK: Run `python tools/export_functions.py` and `tools/check`. Done means the CSV loads in the checker with no errors, the sizes add up to the `.text` size within 1%, and `notes/map.md` gives counts by status and by library.
   BUDGET: Stop after 2 hours or 3 failed exports.
   IF BLOCKED: Stop. Tell me what the exporter could not resolve.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the counts and the size check. 3) Files written. 4) Ranges that look wrong. 5) New parking-lot items.

   Done whendata/functions.csv covers all of .text within 1%, loads in tools/check, and library code is marked.

   Proof this works: BotW decomp (data/uking_functions.csv), ssbu-decomp (data/functions.csv from Ghidra, 39,635 entries), https://github.com/Adubbz/Ghidra-Switch-Loader

4. Match one small function

   You prove the whole chain works on one tiny function. Claude writes C++, builds, and compares. The checker shows no difference. Then the CSV row is updated.

   • Pick a small leaf function with a known name.
   • Write it in C++ without copying Ghidra's output word for word. Keep calls and offsets the same.
   • Run tools/check -mw <function name> to see the diff. It rebuilds on each save.
   • Mark the CSV row. BotW uses m for minor and M for major differences.
   Prompt for ClaudeCopy

   GOAL: Match the function <FUNCTION_NAME> at <ADDRESS> byte for byte.
   READ FIRST: `SCOPE.md`, `data/functions.csv`, the header `<HEADER_PATH>`, Ghidra's view of <ADDRESS>.
   FENCE: Edit only `<SOURCE_FILE>`, `<HEADER_PATH>` and the one CSV row. No inline assembly, no naked functions, no `goto` to force a match.
   CHECK: Run `tools/check <FUNCTION_NAME>`. Done means it reports no difference, and `tools/check` with no argument still prints `OK`.
   BUDGET: Stop after 5 meaningfully different tries.
   IF BLOCKED: Stop. Mark the row `M` or `m`, add a `NON_MATCHING:` comment, and tell me the exact differing instructions.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the check output. 3) Files changed. 4) What you tried. 5) New parking-lot items.

   Done whentools/check <function> shows no difference and the full tools/check prints OK.

   Proof this works: https://botw.link/contribute/how-to-decompile, ssbu-decomp (verify_all.py byte compare)

5. Grind functions in parallel

   Many workers each take one file or one class. Each works in its own git worktree with its own territory. A script reviews each diff for banned tricks. Only verified work is merged.

   • Give each worker exclusive files, as ssbu-decomp's pools do. A lead session merges.
   • Start each worker with claude -w <name> so it gets its own worktree under .claude/worktrees/.
   • A new worktree has no ignored files, such as build/ or the converted main. Link big folders with the worktree.symlinkDirectories setting, or give workers absolute paths.
   • Write a diff reviewer like ssbu-decomp's tools/review_diff.py. It rejects naked functions and raw Ghidra names like uVar1.
   • Run the full tools/check after each merge, not only per function.
   • Send functions that fail 5 tries to the hard queue.
   Prompt for ClaudeCopy

   GOAL: As lead, pick the next <N> unmatched functions under <SIZE> bytes and run one worker per function.
   READ FIRST: `SCOPE.md`, `data/functions.csv`, `notes/PROGRESS.md`, `notes/claims.md`.
   FENCE: You edit only `notes/claims.md` and `notes/PROGRESS.md`. Each worker edits only its claimed source file in its own worktree. Nobody edits `data/functions.csv` except through the merge step.
   CHECK: For each worker, run `tools/check <FUNCTION_NAME>` and `python tools/review_diff.py <BRANCH>` in its worktree. After merging, run `tools/check` on the main branch. Done means every merged function shows no difference and the main branch prints `OK`.
   BUDGET: Each worker stops after 5 tries. Stop the round after <N> functions or 3 hours.
   IF BLOCKED: Stop the worker. Put the function in `notes/hard-queue.md` with the exact differing instructions.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) A table: function, result, check output line. 3) Branches merged. 4) Hard-queue additions. 5) New parking-lot items.

   Done whenEvery merged function passes tools/check, the review script passes, and the main branch prints OK.

   Proof this works: ssbu-decomp (pools on worktrees, review_diff.py), https://github.com/sbergeron42/ssbu-decomp, https://code.claude.com/docs/en/worktrees.md (claude -w, ignored files are absent)

6. Name structs with proof

   Matching needs correct types. Claude reads many functions that touch the same struct offset and builds the struct. Every field name needs a source. Guesses are tagged as guesses.

   • Tag each field as [derived: ...] or [inferred: ...], as ssbu-decomp does.
   • Leave unknown fields as unk_0xNN.
   • Follow BotW's rule: do not reimplement a component you cannot name.
   • Keep placeholder structs in their own folder with a research list.
   Prompt for ClaudeCopy

   GOAL: Define the struct used at <ADDRESS_LIST> with every field typed and sourced.
   READ FIRST: `SCOPE.md`, the functions at <ADDRESS_LIST> in Ghidra, `include/` headers that touch this type.
   FENCE: Edit only `<HEADER_PATH>` and `data/undefined_types.md`. Do not rename anything elsewhere.
   CHECK: Run `ninja -C build` and `tools/check`. Done means the build passes, `tools/check` still prints `OK`, and each field has a `[derived:]` or `[inferred:]` tag naming its source.
   BUDGET: Stop after 90 minutes.
   IF BLOCKED: Stop. List the offsets you could not type and why.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Check output. 3) Files changed. 4) Fields left unknown. 5) New parking-lot items.

   Done whenThe header builds, tools/check prints OK, and every field has a source tag or stays unk_0xNN.

   Proof this works: ssbu-decomp (naming provenance tags), BotW decomp (AGENTS.md: research before reimplementing)

7. Test non-matching code in the recomp

   Some functions will never match with public Clang. You still need proof they work. You swap your C++ into the working recomp in place of the lifted function. Then you replay a route and compare state logs.

   • Use the Path A recomp as the test bench. SSBU Recomp checks decompiled fighter scripts this way.
   • Add a switch that picks the lifted or the decompiled version of each function.
   • Replay the same scripted input with a per-frame state hash log, before and after.
   • Record each function's result in the CSV notes.
   Prompt for ClaudeCopy

   GOAL: Prove the non-matching function <FUNCTION_NAME> behaves like the original.
   READ FIRST: `SCOPE.md`, `<SOURCE_FILE>`, the recomp's override switch doc `<OVERRIDE_DOC>`, the route `<ROUTE_FILE>`.
   FENCE: Edit only the override table `<OVERRIDE_TABLE>` and `notes/`. Do not edit the decompiled function to make the test pass without telling me.
   CHECK: Run `<DETERMINISTIC_RUN> --route <ROUTE_FILE>` with the lifted version, then with the decompiled one. Done means the two state hash logs are identical.
   BUDGET: Stop after 3 runs that differ.
   IF BLOCKED: Stop. Give the first differing log line and the frame.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Both log hashes. 3) Files changed. 4) Functions still untested. 5) New parking-lot items.

   Done whenThe state hash logs from the lifted and decompiled versions are identical on the same route.

   Proof this works: SSBU Recomp (fighter scripts: 20,256 of 23,834 functions equal as C++, checked by differential tests)

8. Port: build the game from source

   You replace lifted functions with your source, one module at a time. The recomp runtime stays as the console layer. Each swap must pass the same golden runs. This is how the decomp reaches other systems.

   • Keep the runtime's NVN-on-Vulkan layer as the graphics interface.
   • Switch modules from lifted to decompiled source behind the override table.
   • Run the regression routes from Path A after each module.
   • Build for a second target only after the PC build passes. LAS Recomp shows one runtime can serve Windows, Linux and macOS.
   Prompt for ClaudeCopy

   GOAL: Build <MODULE> of <GAME> from decompiled source instead of lifted code, and keep every golden run passing.
   READ FIRST: `SCOPE.md`, `notes/PROGRESS.md`, the override table `<OVERRIDE_TABLE>`, `<REGRESSION_COMMAND>` docs.
   FENCE: Edit only the build files for <MODULE> and the override table. Do not change runtime behavior.
   CHECK: Run `<REGRESSION_COMMAND>`. Done means every route passes with <MODULE> fully from source, and the count of lifted functions in <MODULE> is 0.
   BUDGET: Stop after 3 failed regression runs.
   IF BLOCKED: Stop. Name the function and route that fail, with the first differing log line.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Regression output. 3) Files changed. 4) Lifted functions left per module. 5) New parking-lot items.

   Done whenThe module builds from source with 0 lifted functions, and every regression route passes.

   Proof this works: SSBU Recomp (readable C++ where people edit, checked against lifted originals), LAS Recomp (one runtime on Windows, macOS and Linux)

Tools you need

Skills and add-ons

Read any skill before you install it. A skill is a set of instructions that Claude will follow. See Tools and Skills for the full list and safety notes.

Claude setup for this system

Path A units are one missing import, one crash, one shader family or one graphics bug. Each unit has a scripted run with a screenshot or log line as its check. Lifter changes are their own units and must pass the Unicorn test. Path B units are one function, or one source file for a worker in its own worktree. Keep each unit's notes in a numbered file so the next session can read them.

Which model and effort for each job

The model and effort names come from one shared table, so they stay the same on every guide. See Claude Setup for the reasons.

How many sessions at once

Lines for this project's CLAUDE.md

- Read `SCOPE.md` and `notes/PROGRESS.md` before any work. Only the owner changes `SCOPE.md`.
- Generated C is never edited by hand. Change the generator in `recomp/` and regenerate.
- Every lifter change passes the Unicorn test: `<LIFTER_TEST_COMMAND>` must report 0 mismatches.
- Every patch asserts the original instruction word, so a wrong address or version fails loudly.
- Pass the keys file path to tools. Never print, log or copy key values.
- Game files, extracted data and generated code stay in `build/` and `generated/`. Run `python tools/check_content.py --staged` before proposing a commit.
- `refs/` and `tools/vendor/` are read-only. GPL code (yuzu, suyu): read for behavior, write our own.
- A fix counts only when seen working in a scripted run: paste the screenshot path or log line. A clean build is not proof.
- Find the cause first: the faulting address, the wrong value and who wrote it. A stub, clamp, retry or longer timeout needs a comment saying why.
- Never edit the game library ID or a hash file to get past a check. Regenerate and rebuild instead.
- After a build, check the exe's modified time. A failed link leaves the old exe in place.
- Use a scratch save folder for test runs. Never close a game the user is playing. One test window at a time.
- In a worktree, use absolute paths for the dump, `build/` and `generated/`.
- Record dead ends in `notes/PROGRESS.md`: what was checked and why it fell.
- Path B: no inline assembly, naked functions or forced `goto`. Keep a function `NON_MATCHING` instead.

Keep the context small

• Never paste whole logs. Ask Claude to grep for the crash line and the 30 lines before it. TotK Recomp's agent docs say the same.
• Point Claude at file plus function names, not line numbers. Upstream code in refs/ moves.
• Keep AGENTS.md short. TotK, XC2 and Tera Recomp load it with one @AGENTS.md line in CLAUDE.md. An import still loads the whole file, so it saves no context.
• Send Ghidra reading to a subagent and ask for a short report with addresses.
• Start each unit with /clear. The notes files carry state, not the chat.
• Forked docs often still describe the parent game. Tell Claude which docs are current.

More prompts for this system

Each step above has its own prompt. These extra prompts cover the rest of the work. Fill in the parts in <ANGLE_BRACKETS>.

GOAL: Tell me if <GAME> <VERSION> can be brought to PC by static recomp, and which existing Switch recomp to fork.
READ FIRST: `D:/dumps/<GAME>/exefs/main.npdm` (read only), the READMEs of LAS Recomp, TotK Recomp, ssbu-recomp and nxrecomp, the RecompLauncher entries for <GAME>.
FENCE: Write only `notes/feasibility.md` and a draft `SCOPE.md`. Do not clone or build anything.
CHECK: Run `hactool -t npdm --json=notes/npdm.json D:/dumps/<GAME>/exefs/main.npdm`. Done means the report states the `is_64_bit` value from that file, the build ID of `main`, any existing recomp or decomp of this game or engine with links, and one recommended base with its licence.
BUDGET: Stop after 60 minutes.
IF BLOCKED: Stop. Say what you could not confirm. Do not guess.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Each fact with its source. 3) Files written. 4) Risks, such as 32-bit code or a new engine. 5) New parking-lot items.

GOAL: Build `notes/imports.csv` for <GAME>: every imported function, its module and whether the runtime handles it.
READ FIRST: `SCOPE.md`, `D:/dumps/<GAME>/exefs/` (read only), the runtime's handler table `<HANDLER_TABLE>`.
FENCE: Write only `tools/survey.py`, `notes/imports.csv` and `notes/survey.md`. No disassembly in any file.
CHECK: Run `python tools/survey.py D:/dumps/<GAME>/exefs`. Done means every import has a status and the totals in `notes/survey.md` match the script output.
BUDGET: Stop after 90 minutes or 3 failed runs.
IF BLOCKED: Stop. Paste the error.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the totals. 3) Files written. 4) Top 10 missing imports. 5) New parking-lot items.

GOAL: Fix the crash at <CRASH_ADDRESS> seen when <WHAT_THE_PLAYER_DID>.
READ FIRST: `SCOPE.md`, `notes/boot-log.md`, `notes/debug/`, the last 50 lines of `<LOG_PATH>`.
FENCE: Edit only `runtime/` and `notes/`. Never edit `generated/`. Do not add a stub that returns success unless the cause is known and written in a comment.
CHECK: Run `<SCRIPTED_RUN_COMMAND>` before and after. Done means the after-run passes the crash point, the screenshot shows the next scene, and `<REGRESSION_COMMAND>` passes.
BUDGET: Stop after 2 refuted ideas or 90 minutes.
IF BLOCKED: Stop. List each check and what it ruled out.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Cause with evidence and before and after proof. 3) Files changed. 4) New boot-log row. 5) New parking-lot items.

GOAL: Match <FUNCTION_NAME> at <ADDRESS> using the project's Clang.
READ FIRST: `SCOPE.md`, its row in `data/functions.csv`, `<HEADER_PATH>`, two matched functions in the same class as examples.
FENCE: Edit only `<SOURCE_FILE>`, `<HEADER_PATH>` and that one CSV row. No inline assembly, naked functions, forced `goto`, or raw Ghidra names like `uVar1`.
CHECK: Run `tools/check <FUNCTION_NAME>` then `tools/check`. Done means no difference for the function and `OK` for the whole project.
BUDGET: 5 meaningfully different tries.
IF BLOCKED: Stop. Mark the row `m` or `M`, add a `NON_MATCHING:` comment, and report the exact differing instructions.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Check output. 3) Files changed. 4) Tries made. 5) New parking-lot items.

GOAL: Pick the next <N> units from <LEDGER_FILE> and start one worker per unit, each in its own worktree.
READ FIRST: `SCOPE.md`, <LEDGER_FILE>, `notes/claims.md`, `notes/PROGRESS.md`.
FENCE: You edit only `notes/claims.md` and `notes/PROGRESS.md`. Each worker edits only the files its unit names. Only one worker may run the game at a time.
CHECK: For each worker, re-run its check yourself: `<UNIT_CHECK_COMMAND>`. Done means every merged unit passes, and the full check `<FULL_CHECK_COMMAND>` passes on the main branch after merging.
BUDGET: Stop the round after <N> units or 3 hours.
IF BLOCKED: Stop that worker and move its unit to `notes/hard-queue.md` with the evidence.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) A table: unit, worker, result, proof line. 3) Branches merged. 4) Units sent to the hard queue. 5) New parking-lot items.

GOAL: Find the proven cause of <SYMPTOM>. Do not fix it yet.
READ FIRST: `SCOPE.md`, `notes/symptoms.md`, `notes/debug/`, `<LOG_PATH>`.
FENCE: Edit only `notes/debug/<NNN>.md` and temporary debug switches that you list. No fixes in this task.
CHECK: Order the work so the cheapest check that could disprove an idea runs first. Run `<SCRIPTED_RUN_COMMAND>` with your debug switches on, and paste the log lines that prove the cause. Done means `notes/debug/<NNN>.md` names the cause with an address, a value or a frame dump that proves it, and lists every disproved idea.
BUDGET: Stop after 3 disproved ideas or 2 hours.
IF BLOCKED: Stop. List the evidence you have and the one thing you need, such as an emulator run under `gdb`.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The cause and its proof. 3) Disproved ideas. 4) Debug switches added. 5) New parking-lot items.

GOAL: Check that the work on branch <BRANCH> is real.
READ FIRST: `SCOPE.md`, `CLAUDE.md`, the diff `git diff main...<BRANCH>`, the claimed proof in `<REPORT_FILE>`.
FENCE: Read only. Do not fix anything.
CHECK: Re-run `<CLAIMED_CHECK_COMMAND>` yourself. Then search the diff for edits in `generated/`, `tools/vendor/` or `refs/`, changed hash or ID files, new stubs that return success, disabled tests, skipped draws, inline assembly, and changes outside the task's files. Done means a pass or fail for each item with file and line.
BUDGET: Stop after 45 minutes.
IF BLOCKED: Stop. Say which check you could not run.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Your own check output. 3) A table of each cheat check with pass or fail. 4) What must be fixed before merge. 5) New parking-lot items.

GOAL: Report project status with numbers only.
READ FIRST: `SCOPE.md`, `notes/PROGRESS.md`, `notes/imports.csv` or `data/functions.csv`, `notes/hard-queue.md`, `notes/parking-lot.md`.
FENCE: Read only, except `notes/status-<DATE>.md`.
CHECK: Every number comes from a command you ran now, such as `<COUNT_COMMAND>` and `<REGRESSION_COMMAND>`. Paste each command with its output.
BUDGET: Stop after 20 minutes.
IF BLOCKED: Stop. Say which ledger is missing or broken.
OTHER PROBLEMS: List new ones in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Milestone status against `SCOPE.md`. 3) Counts: imports handled, routes passing, or functions matched by status. 4) Top 3 blockers. 5) Parking-lot items for me to decide.

GOAL: Write everything the next session needs into the ledger files.
READ FIRST: `notes/PROGRESS.md`, the current unit's notes, `git status`.
FENCE: Edit only `notes/PROGRESS.md` and the current unit's note file. No code changes.
CHECK: Run `git status` and `git diff --stat`, and paste both. Done means `notes/PROGRESS.md` has today's date, what works with proof, what does not, the leading idea, dead ends with reasons, temporary debug edits still in the code, and the exact next command to run.
BUDGET: 15 minutes.
IF BLOCKED: Stop. Say what you could not record.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The new `notes/PROGRESS.md` section. 3) Files changed. 4) Uncommitted work. 5) New parking-lot items.

GOAL: Tell me plainly whether <UNIT> can be done with what we have.
READ FIRST: `SCOPE.md`, every note about <UNIT> in `notes/`.
FENCE: Read only, except `notes/blocked-<UNIT>.md`.
CHECK: Run the unit's own check `<UNIT_CHECK_COMMAND>` one more time and paste the output. Done means the note says CAN, CANNOT or UNKNOWN, gives the evidence for that answer, and lists at most 3 options with a rough cost each.
BUDGET: 30 minutes.
IF BLOCKED: Say UNKNOWN and name the missing evidence.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) CAN, CANNOT or UNKNOWN in the first line. 3) Evidence. 4) Options. 5) What you need me to decide.

GOAL: Ask me before leaving the fence of the current task.
READ FIRST: `SCOPE.md`, the current task card.
FENCE: Do not edit any file outside the current fence until I answer.
CHECK: Run `git status` and show that no file outside the fence has changed. Done means you wrote `notes/scope-request.md` with the file you want to change, why, the evidence, the risk, and the check that will prove it.
BUDGET: 10 minutes.
IF BLOCKED: Stop and wait for my answer.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The request in five lines. 3) What you will do if I say no.

Keep Claude on task

These are the detours Claude tends to take on this system, and the rule that stops each one. The full method is on Stay on Task.

Problems other projects hit

How long it takes

What makes it faster or slower

• Whether a recomp exists for a game on the same engine. Forks reached a title screen in one or two days.
• Code size. Big games mean long lifts and compiles, often 5 to 45 minutes per build.
• How many new NVN calls and shader features your game uses that the base lacks.
• Whether the game is 64-bit. A 32-bit game needs a new lifter.
• For Path B, how close a public Clang is to the game's SDK compiler.

The facts behind these numbers

Projects reviewed (15)

All 15 RecompLauncher Switch projects we reviewed: the top-starred project for each of the top 12 games, plus 3 the catalog flags as AI-made. The catalog lists 67 Switch projects for 46 games, and every one is a recomp or port. Path B evidence comes from three decomps outside RecompLauncher: BotW, Odyssey and ssbu-decomp.

What each project teaches

What we could not check

• Sky Recomp's repo returned 404, so its tools, dates and AI use are unknown.
• FEFW Recomp's README calls its game a Switch 2 title. The catalog files it under Switch.
• The BotW docs define only m and M in the function list. The meaning of O, W, L and U was not confirmed.
• The Clang version the Odyssey decomp uses was not found. Its setup downloads tools from a cache repo.
• decomp.me handles Switch code, since BotW's docs give a tools/decompme script for it. Which Switch compilers decomp.me offers was not checked.
• No command in this guide was run here. Each one comes from the tool's own docs or a project card. No game files were used.
• How TotK Recomp fixed the stlr and ldar order problem is not in its docs.
• The winget lines for the .NET SDK and Build Tools come from TotK's docs and the winget manual. They were not run here.
• How to attach gdb to Ryujinx, as Tera Recomp did, was not checked.
• No reviewed project says how many hours of human attention it took. The time ranges are estimates.
• Several projects hide earlier history: Savage Wind squashed its imported history, and Metroid Dread's repo was made five weeks before its first commit.
• The packages in the MSYS2 install line come from MHGU Recomp's README, not from a test run here. The TotK family needs a longer list.
• The upstream SwitchRecomp (MZ Labs) and SwitchGamesRecomp repos are not linked from the projects that use them.

Sources

• LAS Recomp README
• TotK Recomp README and AGENTS.md
• nxrecomp README
• ssbu-decomp README
• BotW decomp AGENTS.md
• BotW decomp installation guide
• BotW decomp: how to decompile
• OdysseyDecomp README
• OdysseyDecomp progress on decomp.dev
• nx-decomp-tools
• Switchbrew: NSO
• Switchbrew: ExeFS
• Switchbrew: NPDM
• Switchbrew: NCA
• Switchbrew: SVC
• deko3d README (Tegra X1 and NVN)
• Ghidra-Switch-Loader
• Ghidra README and releases
• hactool README
• objdiff README
• REA README
• MSYS2
• uv README
• llvm-mingw README
• Unicorn on PyPI
• Capstone on PyPI
• Vulkan SDK latest version
• TotK Recomp docs/building.md
• TotK Recomp docs/agents/running.md
• MHGU Recomp README (MSYS2 packages, WSL notes)
• Ghidra 12.1.2 README (JDK 21)
• hactool npdm.c (is_64_bit in JSON output)
• BotW decomp progress badge
• OdysseyDecomp on decomp.dev (JSON)
• ssbu-decomp review_diff.py
• Claude Code: worktrees
• Claude Code: memory and imports
• Ryujinx (Ryubing)
• rustup
• winget install command
• ziglang on PyPI