PlayStation Portable decomp guide

What this system is like

The PSP is a busy system for recomp work right now. Two shared tools, PortableKit and PSPRecomp, turn a game's code into C++. A recomp is a tool that rewrites machine code as C or C++. More than twenty PSP games have recomp ports. Most of them came out in late 2026, and most used AI help.

The usual route to a PC build is short. You decrypt the game's main file. You run it under a slow stand-in for the CPU, called an interpreter, to see what is missing. Then you turn all the code into C++, build it, and fix one gap at a time.

A full decomp is much harder here. A decomp is readable C that builds back to the exact same bytes. PSP games used three compiler families, much C++ code, and often more than ten thousand functions. No PSP game is fully decompiled yet. One project matched about 41% of a game's code in four weeks with AI agents. That is the best sign so far.

Path A runs on Windows. Path B needs WSL, because the old compilers run there through wibo. Ghidra, PPSSPP and objdiff run on Windows for both paths.

Two paths

Path A: Get it running on PC

You build a game profile on PortableKit. Its installer checks and decrypts your own disc. You run the game under its interpreter to list what is missing. Then psp_recomp writes the C++, and you fix one gap at a time. PSPRecomp also works, but it has no interpreter and no installer.

1. Scope the game and survey the disc

   You pick one game, one region and one version. You look for earlier work on it. Then you measure the disc so you know the risks before you write code.

   • Note the disc ID, like ULUS10160, from PARAM.SFO or UMD_DATA.BIN.
   • Search RecompLauncher, the PortableKit ports table and GitHub for your game. Look for a recomp, a decomp or a sister game on the same engine.
   • Check if PSP_GAME/SYSDIR/EBOOT.BIN is encrypted or if a plain BOOT.BIN exists.
   • List extra .prx files and big data files that may hold overlays.
   • Play the game in PPSSPP and note the frame rate and any odd features.
   • Have Claude write SCOPE.md. You approve it.
   Prompt for ClaudeCopy

   GOAL: Write a draft SCOPE.md for a PC recomp of <GAME> (<DISC_ID>, version <VERSION>).
   READ FIRST: `notes/disc-listing.txt` (my file list of the disc), the `PortableKit` README, `docs/BRINGING_UP_A_GAME.md` in PortableKit.
   FENCE: Edit only `SCOPE.md` and `notes/survey.md`. Everything else is read-only. Do not write code, scripts or configs.
   CHECK: `SCOPE.md` has these headings: Goal, Game and hash, Technique, Prior work, Disc survey, Milestone 1 and its check, Out of scope, Never edit. Every claim in Prior work has a URL.
   BUDGET: Stop after 45 minutes of research.
   IF BLOCKED: Stop. Do not guess facts about the disc. List what you need me to look up.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not act on them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The SCOPE.md headings filled. 3) Files changed. 4) Open questions for me. 5) New parking-lot items.

   Done whenSCOPE.md names the disc ID, the executable hash, the framework and the first milestone, and you approved it.

   Proof this works: The 3rd Birthday Recomp (step 0 survey and bake-off), God of War PSP (feasibility study before code), MHForever (measured candidate recompilers first)

2. Set up the framework and the repo

   You build the framework alone first. It needs no game and takes minutes. Then you make your port repo with the framework as a git submodule. You add the one boot check and the guard against game files.

   • Install Visual Studio 2022 with the C++ workload, CMake 3.20 or newer, Ninja and Python 3. A port also needs SDL3, the Vulkan SDK (it has glslangValidator) and FFmpeg.
   • Run git clone --recursive https://github.com/TeamGDB/PortableKit.git and build it with cmake -S . -B out -G Ninja -DCMAKE_BUILD_TYPE=Release, cmake --build out -j2 and ctest --test-dir out --output-on-failure. On Windows, run these in a Visual Studio developer prompt.
   • Or use the Visual Studio generator. Then add --config Release to the build and -C Release to ctest.
   • The bundled FFmpeg needs make and a C compiler. Without them, pass -DPORTABLEKIT_FFMPEG=system, or OFF to drop music and movies.
   • In your own repo, add it with git submodule add https://github.com/TeamGDB/PortableKit.git portablekit.
   • Write the profile in host/<game>_profile.cpp. It holds only constants: disc ID, both hashes, decryption tag and key, load address and save folders.
   • Read each value off your own disc and its ELF headers, as PROFILE_GUIDE.md says. Do not recall them.
   • Make .gitignore deny everything first, then allow your own folders. Add a pre-commit check that refuses game files and generated code.
   • Have Claude write tools/boot_check.py with --seconds N, --no-interpreter and --replay <FILE>. It runs the game with no window and no sound, kills it at the limit, and prints PASS or FAIL.
   • Write CLAUDE.md, PROGRESS.md and notes/parking-lot.md.
   Prompt for ClaudeCopy

   GOAL: Make the port repo build with PortableKit as a submodule and one check command that runs.
   READ FIRST: `SCOPE.md`, `portablekit/README.md`, `portablekit/docs/PROFILE_GUIDE.md`, `portablekit/docs/BUILDING.md`.
   FENCE: Edit only `CMakeLists.txt`, `host/`, `config/`, `tools/boot_check.py`, `.gitignore`, `.githooks/`, `CLAUDE.md`, `PROGRESS.md`. `portablekit/` is read-only. Do not add features I did not ask for.
   CHECK: Run `cmake --build out -j2` then `ctest --test-dir out --output-on-failure`. Done means both exit 0, and `python tools/boot_check.py --help` lists `--seconds`, `--no-interpreter` and `--replay`.
   BUDGET: Stop after 3 failed builds with the same error, or 60 minutes.
   IF BLOCKED: Stop. Do not edit the submodule to make it build. Tell me the error, what you tried and what you need.
   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 test output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whencmake --build and ctest exit 0 on a clean clone, and a test commit with a fake .iso file is refused.

   Proof this works: https://github.com/TeamGDB/PortableKit, Portable Ops Native (PortableKit as a submodule), MHForever (content guard as a pre-commit hook), Renegade Squadron PC (default-deny .gitignore)

3. Prepare and pin the executable

   You turn your disc into a decrypted executable. You pin its hash so every later step uses the same bytes. A wrong key or version shows up here in seconds.

   • With PortableKit, run <Game>Native --install /path/to/your.iso --in-place. It checks the disc ID and the EBOOT.BIN SHA-256, then decrypts.
   • Without it, decrypt EBOOT.BIN with pspdecrypt from its release zip.
   • If the disc has a plain ELF BOOT.BIN, use that and skip decryption.
   • Put both hashes in the profile: encrypted_executable_sha256 for EBOOT.BIN and executable_sha256 for the decrypted file.
   • Keep the .iso and the decrypted file outside the repo.
   Prompt for ClaudeCopy

   GOAL: Make the install step produce a decrypted executable whose SHA-256 matches the value pinned in the profile.
   READ FIRST: `SCOPE.md`, `host/<GAME>_profile.cpp`, `portablekit/docs/PROFILE_GUIDE.md`, `portablekit/docs/BRINGING_UP_A_GAME.md` step 2.
   FENCE: Edit only the identity, hash and decryption constants in `host/<GAME>_profile.cpp`. Never copy game files into the repo. Never print keys into logs or notes.
   CHECK: Run `<Game>Native --install <ISO_PATH> --in-place`. Done means it exits 0 with no disc ID, hash or key error. The installer checks the decrypted file against `executable_sha256` itself.
   BUDGET: Stop after 3 failed tries.
   IF BLOCKED: Stop. Do not search the web for keys or download any game file. Tell me which check failed and its exact message.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the install output. 3) Files changed. 4) What is left.

   Done when<Game>Native --install exits 0. It has checked the disc ID, the EBOOT.BIN hash and the decrypted file against the pinned hash.

   Proof this works: Yakumo (installer checks PARAM.SFO and the EBOOT.BIN SHA-256), Vice City Stories Recomp (refuses an ELF whose hash does not match), Sims 2 PSP Recomp (uses the plain BOOT.BIN)

4. Map the executable

   You load the decrypted file into Ghidra to see functions, imports and overlays. You save a ledger of what the game needs. This is where you learn the size of the job.

   • Install Ghidra 12.1.4 and the ghidra-allegrex zip built for 12.1.4 with File -> Install Extensions. Extensions must match the Ghidra version.
   • Import the decrypted file. Set Image Base to 08804000. Run auto analysis.
   • In PPSSPP, save a .sym file from the Debug menu. Import it with the PpssppImportSymFile script. Start Ghidra with support\pyghidraRun.bat on Windows for this.
   • Run portablekit/tools/ghidra/ExportPSPFunctions.java from the Script Manager. It writes a CSV of name, address and size. Add a status column.
   • List the imports by library. This is your list of system calls to support.
   • Mark SDK and middleware functions so nobody works on them by hand.
   • Find the function that loads overlays, if the game has them.
   Prompt for ClaudeCopy

   GOAL: Produce `ledger/functions.csv` and `ledger/imports.md` for <GAME>.
   READ FIRST: `SCOPE.md`, `notes/survey.md`, the Ghidra export at `<EXPORT_PATH>`.
   FENCE: Edit only files in `ledger/`. The Ghidra project and the game files are read-only. Do not rename anything in Ghidra unless I ask.
   CHECK: `ledger/functions.csv` has columns address, size, name, kind (game, sdk, middleware), status. Its row count equals the row count of the export at `<EXPORT_PATH>`. `ledger/imports.md` lists every import by library with its NID.
   BUDGET: Stop after 60 minutes.
   IF BLOCKED: Stop. Do not invent names or NIDs from memory. Tell me what is missing.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Counts: functions, SDK functions, imports, overlays found. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenledger/functions.csv has as many rows as the ExportPSPFunctions CSV, and every import is listed with its library.

   Proof this works: God of War PSP (Ghidra + ghidra-allegrex exports to JSON), https://github.com/kotcrab/ghidra-allegrex, The 3rd Birthday Recomp (import list as the HLE checklist)

5. First light under the interpreter

   You run the game before any code is recompiled. The interpreter runs it slowly but truly. Each run names the next missing system call. Each fix costs seconds, not hours.

   • Run <PREFIX>_NO_RENDER=1 <PREFIX>_NO_AUDIO=1 timeout 90 <Game>Native. Your tools/boot_check.py does the same on Windows.
   • Add <PREFIX>_LIST_STUBS=1 to print every import nothing implements.
   • Read the last [hle-stub] line before a Runtime stopped message. That call is the next job.
   • Set <PREFIX>_STRICT_HLE=1 so the game stops at a missing call instead of going on with a fake answer.
   • Implement that one call through the profile's register_extra_hle hook or an HLE extension. Run again.
   • A run with a window may not stop on a plain timeout. Use timeout -s KILL, and never leave the game running.
   Prompt for ClaudeCopy

   GOAL: Implement the system call `<LIBRARY>::<FUNCTION>` so the interpreter boot gets past it.
   READ FIRST: `CLAUDE.md`, the last boot log at `<LOG_PATH>`, `ledger/imports.md`, `PPSSPP` source for this call (read only, never copy).
   FENCE: Edit only the HLE files in `host/` that `register_extra_hle` reaches, or the HLE extension file I name. `portablekit/` is read-only. Do not stub other calls.
   CHECK: Run `python tools/boot_check.py --seconds 90`. Done means the log no longer stops at this call, and the earlier boot milestones in `PROGRESS.md` still print.
   BUDGET: Stop after 3 failed tries or 45 minutes.
   IF BLOCKED: Stop. Do not return a fake success code to move on. Tell me what the game expects and what you could not confirm.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the log lines before and after. 3) Files changed. 4) The next call the game stops on. 5) New parking-lot items.

   Done whenpython tools/boot_check.py --seconds 90 runs past the call, and the log names the next stop or shows the title screen.

   Proof this works: https://github.com/TeamGDB/PortableKit/blob/main/docs/BRINGING_UP_A_GAME.md, Tag Force Recomp (every missing call fails loudly), Ape Escape Mind Over Monkey (bind a call only when its contract is known)

6. Recompile and boot with no interpreter

   Now you turn all the code into C++ and build it. The build is long, so keep jobs low. Then you prove the boot uses only recompiled code.

   • Run psp_recomp <EBOOT.ELF> --auto generated. It takes a few minutes.
   • Count the unsupported(...) sites in the output before you compile. Thousands in one category means a real recompiler gap.
   • Build with cmake --build out -j2. Generated files are huge, so the build compiles only one per 4 GiB of memory.
   • Use clang-cl for the generated code if you can. In one port, frames took 7 ms with it and 18 to 22 ms with MSVC.
   • Run with PSPRECOMP_NO_INTERPRETER=1. The runtime stops at the first address with no recompiled code and names it.
   • With the interpreter on, PSPRECOMP_INTERPRETER_VERBOSE=1 lists every address it had to run. Recompile the code those belong to.
   • If the game has overlays, extract each one and recompile it into its own library with portablekit/tools/add_overlay.py. Pick the right one at run time by a hash of its code.
   Prompt for ClaudeCopy

   GOAL: Generate and build the recompiled game, and boot it to <MILESTONE> with the interpreter off.
   READ FIRST: `CLAUDE.md`, `PROGRESS.md`, `portablekit/docs/BRINGING_UP_A_GAME.md` step 4.
   FENCE: Edit only `host/`, `config/` and build settings in `CMakeLists.txt`. Never edit files in `generated/`. If generated code is wrong, report it; the fix goes in the generator or the profile.
   CHECK: Run `python tools/boot_check.py --seconds 120 --no-interpreter`. It sets `PSPRECOMP_NO_INTERPRETER=1`. Done means PASS, the log shows <MILESTONE>, and no `Runtime stopped` line names a missing address.
   BUDGET: Use `-j2` at most. Stop after 2 full builds that fail the same way.
   IF BLOCKED: Stop. Do not turn the interpreter back on to pass. List the first missing address and what code it belongs to.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the unsupported-site counts and the boot log tail. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenpython tools/boot_check.py --no-interpreter prints PASS at the milestone, and no missing address stops the run.

   Proof this works: Dissidia012-PC (no interpreter fallbacks proved this way; VERBOSE listed a missed disc PRX), Portable Ops Native (stage sweep with the interpreter off), Vice City Stories Recomp (clang-cl about 2.5x faster frames than MSVC), Yakumo (355 overlays, each its own library)

7. Grind: one gap at a time

   Each task is one crash, one missing call or one drawing bug. Claude finds the cause with traces first. PPSSPP is your reference for how the real system acts.

   • Turn on one trace at a time, like <PREFIX>_TRACE_GE_LIST, <PREFIX>_TRACE_IO or <PREFIX>_TRACE_SYNC.
   • Compare with PPSSPP at the same load base. Use its debugger to watch memory writes.
   • Write each fix with its cause and the trace that proved it in PROGRESS.md.
   • Record dead ends too, so no session tries them again.
   • Keep a list of bugs as GitHub issues or a ledger table. Hand out one per worker.
   Prompt for ClaudeCopy

   GOAL: Fix <BUG> (seen at <WHERE>) with a proven cause.
   READ FIRST: `CLAUDE.md`, `PROGRESS.md` dead ends, the log at `<LOG_PATH>`, the capture at `<CAPTURE_PATH>`.
   FENCE: Edit only `host/` and `config/`. `generated/` and `portablekit/` are read-only. No game-specific hacks that skip the bug.
   CHECK: Run `python tools/boot_check.py --replay <REPLAY_FILE>`. Done means PASS, the bug is gone in the capture at frame <N>, and all older replays still pass.
   BUDGET: Find the cause before any fix. Stop after 2 fixes that do not work, or 90 minutes.
   IF BLOCKED: Stop. Tell me the evidence you have, your best theory and what trace would prove it.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`. Do not fix them.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The cause, with the trace lines that prove it. 3) Files changed. 4) Replay results. 5) New parking-lot items.

   Done whenThe replay passes, the capture shows the fix, and every older replay still passes.

   Proof this works: Yakumo (AGENTS.md: trace the hardware, measure before changing), The 3rd Birthday Recomp (PPSSPP as oracle, dated fix log), Tag Force Recomp (TF_HOOK_TRACE found a wrong address in minutes)

8. Harden: replays, frames and packaging

   You lock in old fixes with tests that run without you. Then you add settings and package a release that holds no game code. The player builds the game from their own disc.

   • Record input sessions and make headless runs repeat exactly. Pin the clock and the gamepad.
   • Keep a slow software renderer as the reference. Compare the GPU output against it frame by frame.
   • Write a script that visits every level or stage and reports crashes and missing calls.
   • Run tests that need no game data in CI.
   • Package only the runtime and launcher. The launcher builds the game on the player's PC.
   • State in the release notes what you tested and what you did not.
   Prompt for ClaudeCopy

   GOAL: Add `tools/regress.py`, a regression set a fresh checkout can run: replays at fixed frames, a stage sweep and a `--no-interpreter` switch.
   READ FIRST: `CLAUDE.md`, `PROGRESS.md`, `tools/boot_check.py`.
   FENCE: Edit only `tools/` and `tests/`. Do not change game behaviour to make a test pass. Do not commit replays that hold game data.
   CHECK: On a clean clone, run `python tools/regress.py`. Done means it prints PASS for every replay and every stage, then a summary line with the counts.
   BUDGET: Stop after 90 minutes or 3 failed designs.
   IF BLOCKED: Stop. Tell me which run is not repeatable and what changes between runs.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the summary line. 3) Files changed. 4) What the set does not cover. 5) New parking-lot items.

   Done whenpython tools/regress.py prints PASS for all replays and stages on a clean clone.

   Proof this works: God of War PSP (34/34 identical frames, WAV hash, level tour), Renegade Squadron PC (GPU compared to the software renderer), LCS Recomp (stress test with numeric pass and fail), Sims 2 PSP Recomp (900-frame startup check, per-release status log)

Path B: Full decomp for porting

You split each module with splat, find the original compiler by test, and match functions one by one. A match means the old compiler turns your C into the exact same bytes. The tools run in WSL. No PSP game is fully done yet, so this path is still being worked out.

1. Scope and find the compiler

   You check what decomp work exists for your game. Then you find which compiler and flags built it. You test candidates on a few small functions and count exact matches.

   • Search GitHub and decomp.dev for your game and its engine. Check sotn-decomp, mhp2g-decomp and HST-Decomp for setups you can copy.
   • Pick three to six small functions from the smallest module.
   • Compile each with every candidate: mwccpsp builds, pspsnc, psp-gcc 1.3.1 and 1.7.1, at common flags.
   • Count exact matches for each compiler and flag set.
   • Write the winner and its flags into SCOPE.md.
   Prompt for ClaudeCopy

   GOAL: Find the compiler and flags that built <GAME>, by experiment.
   READ FIRST: `SCOPE.md`, the six target functions in `asm/<MODULE>/`, `notes/compilers.md`.
   FENCE: Edit only `notes/compilers.md` and files under `try/compiler-test/`. Everything else is read-only.
   CHECK: For each compiler and flag set, run `<MATCH_TOOL> try/compiler-test/<FUNC>.c`. Done means `notes/compilers.md` has a table of exact matches per compiler and flag set, with the command used.
   BUDGET: Stop after testing every candidate once, or 90 minutes.
   IF BLOCKED: Stop. Do not download compilers from unknown sites. Tell me which candidate you could not run.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The match table. 3) Files changed. 4) Your pick and why. 5) New parking-lot items.

   Done whenOne compiler and flag set matches every test function exactly, and the table is in notes/compilers.md.

   Proof this works: Dissidia012-PC (SNC matched 5 of 6 at -O2, 6 of 6 with -g), https://github.com/angelof-exe/ygo-tf-5-decomp (mwccpsp_3.0.1_219, flags -O4,s; builds 180 to 219 all match its simple functions), https://github.com/decompme/compilers (PSP compiler kits)

2. Set up the matching build in WSL

   You set up WSL with the splitter, the disassembler, an Allegrex assembler, the diff tool and the old compiler. The build must check the hash of every module. One command builds and checks all.

   • In WSL (Ubuntu 24.04), run sudo apt-get install binutils-mipsel-linux-gnu ninja-build python3-venv libc6-i386. Then make a venv with python3 -m venv .venv.
   • libc6-i386 is needed because the Sony psp-gcc kits are 32-bit Linux programs.
   • Install the Python tools with .venv/bin/python3 -m pip install -U splat64[mips] spimdisasm ninja_syntax.
   • Stock binutils may not know Allegrex. Get allegrex-as.tar.gz from the cc1-psx-26 release of sotn-decomp, check its SHA-256, and unpack it.
   • Download wibo-i686 (1.2.0) and objdiff-cli-linux-x86_64 from their release pages. Run chmod +x on both.
   • Download your kit, like mwccpsp_3.0.1_219.tar.gz, from the compilers release of decompme/compilers. Unpack it in bin/ on the Linux file system, outside Git.
   • Pin the kit's SHA-256 in a file, like mhp2g-decomp does with bin/mwccpsp_219.tar.gz.sha256.
   • Add mwccgap as a submodule if you use CodeWarrior. It lets C files hold not-yet-matched functions as assembly. Point its --as-path at the Allegrex assembler.
   • Write configure.py that writes a build.ninja. The last build step runs sha1sum -c on every module.
   Prompt for ClaudeCopy

   GOAL: Make `ninja` build the module <MODULE> from its assembly and check its SHA-1.
   READ FIRST: `SCOPE.md`, `notes/compilers.md`, `configure.py`, the setup of `tclamb/mhp2g-decomp` as a model.
   FENCE: Edit only `configure.py`, `config/`, `tools/` and `requirements.txt`. Never edit the checksum files in `config/*.sha1`. Never commit compilers or game files.
   CHECK: In WSL, run `python3 configure.py && ninja`. Done means it exits 0 and the last line shows the module's `sha1sum -c` OK.
   BUDGET: Stop after 3 failed tries with the same error, or 60 minutes.
   IF BLOCKED: Stop. Do not change a checksum to pass. Tell me the error and what you need.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the `ninja` output tail. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenninja exits 0 and sha1sum -c reports OK for the module built from assembly.

   Proof this works: https://github.com/tclamb/mhp2g-decomp (configure.py, mwccgap, wibo, sha1sum, patched Allegrex assembler), Dissidia012-PC tools/setup_wsl.sh (binutils-mipsel-linux-gnu plus allegrex-as from sotn-decomp), Dissidia012-PC (SNC through wibo in WSL Ubuntu 24.04), https://github.com/decompals/wibo

3. Split each module

   splat cuts a module into code, data and a linker script. Start with the smallest module. Overlays and extra .prx files are separate modules.

   • Write a splat config per module in config/<module>.yaml.
   • Run python3 -m splat split config/<module>.yaml.
   • Fix segment edges until the module rebuilds from assembly with the right hash.
   • If the splat linker script pads segments, write your own linker script.
   • Keep symbol_addrs.txt as the one place for names.
   Prompt for ClaudeCopy

   GOAL: Split <MODULE> with splat so it rebuilds byte for byte from assembly.
   READ FIRST: `config/<MODULE>.yaml`, `notes/compilers.md`, the splat wiki page on segments.
   FENCE: Edit only `config/<MODULE>.yaml`, `config/<MODULE>.symbol_addrs.txt` and the module linker script. Never edit files in `asm/` by hand; they are generated.
   CHECK: In WSL, run `python3 -m splat split config/<MODULE>.yaml && ninja`. Done means `sha1sum -c` prints OK for <MODULE>.
   BUDGET: Stop after 5 split attempts with no progress, or 60 minutes.
   IF BLOCKED: Stop. Tell me which segment edge is wrong and the bytes around it.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the `sha1sum` line. 3) Files changed. 4) Segments still unsure. 5) New parking-lot items.

   Done whenThe module rebuilt from split assembly passes sha1sum -c.

   Proof this works: Dissidia012-PC (splat linker script replaced by a hand-written one), https://github.com/ethteck/splat, https://github.com/angelof-exe/ygo-tf-5-decomp (section-accurate splat config)

4. Map functions and mark library code

   You build the function ledger. You mark SDK and middleware code so no one matches it by hand. You find repeated functions, because one match can solve many.

   • Export the function list with sizes from Ghidra or the splat output.
   • Mark Sony SDK, C library and middleware functions in the ledger.
   • Find functions with the same bytes. A match for one is a match for all copies.
   • Sort the rest by size. Small leaf functions go first.
   • Set up objdiff with an objdiff.json so it can report progress.
   Prompt for ClaudeCopy

   GOAL: Build `ledger/functions.csv` for <MODULE> with kind, size, duplicate group and status.
   READ FIRST: `config/<MODULE>.symbol_addrs.txt`, the Ghidra export at `<EXPORT_PATH>`, `ledger/README.md`.
   FENCE: Edit only `ledger/`. Everything else is read-only.
   CHECK: Run `python3 tools/ledger_check.py`. Done means it prints OK: every function in the module is in the ledger once, and each has a kind and a status.
   BUDGET: Stop after 60 minutes.
   IF BLOCKED: Stop. Do not guess library names. Mark unsure rows as unknown and tell me how many.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Counts by kind and the number of duplicate groups. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whentools/ledger_check.py prints OK and every function has a kind and a status.

   Proof this works: https://github.com/Jstar269/HST-Decomp (SDK code kept out; duplicates reused by a tool), Tag Force Recomp (pick functions by session coverage)

5. Match the first function

   You match one small function end to end. This proves the compiler, flags and build. Then the whole module must still pass its hash.

   • Pick a small leaf function from the smallest module.
   • Get a draft from m2c on its assembly.
   • Edit the C until objdiff shows 100% for that function.
   • Replace its INCLUDE_ASM line with the C.
   • Run the full build. The module hash must still match.
   Prompt for ClaudeCopy

   GOAL: Make `<FUNCTION>` in `src/<MODULE>/<FILE>.c` match exactly.
   READ FIRST: `asm/<MODULE>/<FUNCTION>.s`, `notes/compilers.md`, `notes/compiler-quirks.md`.
   FENCE: Edit only `src/<MODULE>/<FILE>.c` and headers in `include/` that this function needs. No inline asm, no `.word`, no `.incbin`, no `#pragma` tricks.
   CHECK: In WSL, run `ninja`. Done means objdiff shows 100% for `<FUNCTION>` and `sha1sum -c` prints OK for the whole module.
   BUDGET: Stop after 10 attempts with no gain. Save each attempt as a new file in `try/<FUNCTION>/`.
   IF BLOCKED: Stop. Report the best score, the remaining differing instructions and your theory.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the objdiff score and the sha1sum line. 3) Files changed. 4) Compiler lessons learned.

   Done whenobjdiff shows 100% for the function and the full module passes sha1sum -c.

   Proof this works: Dissidia012-PC (started on the 24 KB extra overlay), https://github.com/angelof-exe/ygo-tf-5-decomp (smallest module first, 15 of 16 matched), https://github.com/matt-kempster/m2c

6. Bulk grind with many workers

   Now you match many functions in parallel. A script picks the next units, not the model. Duplicates and tool output go first, then small functions, then bigger ones.

   • Let tools handle repeated code and plain translations first. They cost no tokens.
   • Give each worker its own git worktree and its own slice of the ledger.
   • One function per session. Clear the chat between functions.
   • Workers save near misses in wip/ with a note. Only exact matches go in src/.
   • Merge one branch at a time. Run the full build after each merge.
   Prompt for ClaudeCopy

   GOAL: Match the functions in batch <BATCH_ID> from `ledger/batches/<BATCH_ID>.txt`, one at a time.
   READ FIRST: `CLAUDE.md`, `notes/compiler-quirks.md`, the batch file. Nothing else unless a function needs it.
   FENCE: Work only in worktree `<WORKTREE_PATH>`. Edit only the `src/` files of functions in this batch and `wip/`. Never edit `asm/`, `config/*.sha1`, `tools/` or the ledger.
   CHECK: After each function, run `ninja`. A function is done only when objdiff shows 100% and `sha1sum -c` prints OK.
   BUDGET: At most 5 serious attempts per function. Then save the best try in `wip/` with a note and move on.
   IF BLOCKED: Stop the batch. Tell me what broke the build and the last good commit.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) A table: function, result, attempts. 3) Files changed. 4) Functions left. 5) New parking-lot items.

   Done whenEvery function in the batch is either matched with a passing build or saved in wip/ with a note.

   Proof this works: https://github.com/Jstar269/HST-Decomp (tools first, agents on the rest, 41% of code in about four weeks), https://blog.chrislewis.au/the-unexpected-effectiveness-of-one-shot-decompilation-with-claude/ (Snowboard Kids 2: one function per headless run)

7. Work the hard tail

   Some functions resist the bulk workers. They need a stronger job type and a shared file of compiler lessons. Some may never match without a trick, and that is allowed to stay open.

   • Send units that failed five bulk tries to the hard queue.
   • Keep notes/compiler-quirks.md short and general. No notes about single functions.
   • Check VFPU code. Allow inline VFPU asm only where the original used it, and mark it.
   • Try the other compiler kits only for functions the main one cannot reproduce.
   • Leave a function non-matching rather than accept a fake match.
   Prompt for ClaudeCopy

   GOAL: Match `<FUNCTION>`, which failed 5 bulk attempts.
   READ FIRST: `wip/<FUNCTION>.c` and its note, `asm/<MODULE>/<FUNCTION>.s`, `notes/compiler-quirks.md`.
   FENCE: Edit only `src/<MODULE>/<FILE>.c`, `wip/<FUNCTION>.c` and `notes/compiler-quirks.md` (general lessons only). No asm that emits non-VFPU instructions, no `.word`, no data in `.text`.
   CHECK: Run `ninja`. Done means 100% in objdiff and `sha1sum -c` OK.
   BUDGET: Stop after 15 attempts with no gain. Save each try in `try/<FUNCTION>/`.
   IF BLOCKED: Stop. Name the exact differing instructions and a theory class, not a vague guess. Say if it may need a different compiler build.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Best score and the diff summary. 3) Files changed. 4) The lesson for `compiler-quirks.md`, if general.

   Done whenThe function matches with a passing build, or it is left in wip/ with the exact remaining differences named.

   Proof this works: https://github.com/Jstar269/HST-Decomp (VFPU inline asm rule, secondary compiler only for leftovers), Dissidia012-PC (-g changes SNC scheduling; twelve functions differ without it)

8. Harden: gates, review and progress

   You add checks that catch fake matches. A fresh agent re-checks claimed work. CI rebuilds everything from scratch on a machine Claude cannot touch.

   • Write a gate script that rejects .word, .incbin, non-VFPU asm and data forced into code.
   • Block edits to config/*.sha1 and tools/ with a Claude Code hook.
   • Run a fresh verify session on every merged batch.
   • Have CI run configure.py and ninja from a clean clone.
   • Publish an objdiff progress report on each merge.
   Prompt for ClaudeCopy

   GOAL: Verify the matches claimed in branch <BRANCH> and hunt for cheating.
   READ FIRST: `CLAUDE.md`, the diff of <BRANCH> against main, `tools/gate.py`.
   FENCE: Read only. Do not fix anything. Write findings only in `notes/verify-<BRANCH>.md`.
   CHECK: On a clean clone, run `python3 configure.py && ninja && python3 tools/gate.py`. Done means you report each claimed function as REAL or FAKE with proof.
   BUDGET: Stop after 60 minutes.
   IF BLOCKED: Stop. Tell me what you could not check and why.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the build and gate output. 3) A table: function, REAL or FAKE, reason. 4) Any edits outside the fence in the diff. 5) Any changed checksum or tool file.

   Done whenA clean clone builds, sha1sum -c passes, the gate passes, and the verify note lists no fake matches.

   Proof this works: https://github.com/Jstar269/HST-Decomp (hstgate.py rejects fake matches), https://github.com/cdlewis/snowboardkids2-decomp/tree/main/.claude/hooks (hooks block checksum and asm edits)

9. Port: swap recompiled code for your C

   No PSP game has a finished decomp port yet. The realistic route is a hybrid. Your matched C replaces recompiled functions inside the Path A runtime. When every function is C, you drop the generated code.

   • Hook each recompiled function so your C can run in its place.
   • Add a --verify-overrides switch to tools/regress.py. It runs the original and your C from the same state, like Tag Force's TF_DECOMP_VERIFY.
   • Run the old and new versions from the same state and compare results.
   • Grow the C part one module at a time, driven by your replays.
   • Move system calls behind one interface so the runtime can change.
   • Fix 64-bit pointer and byte-order issues before a new target.
   • Build for the new system and run the same replays.
   Prompt for ClaudeCopy

   GOAL: Replace the recompiled `<FUNCTION>` with the decomp C in the Path A runtime.
   READ FIRST: `src/<MODULE>/<FILE>.c`, the hook table in `host/`, `PROGRESS.md`.
   FENCE: Edit only the override file in `host/overrides/` and the hook table. Never edit `generated/`. Do not change the matched source.
   CHECK: Run `python tools/regress.py --verify-overrides`. Done means the original and the override give the same results from the same state, and all replays pass.
   BUDGET: Stop after 3 failed tries.
   IF BLOCKED: Stop. Tell me which value differs, where, and your theory.
   OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
   REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Paste the compare and replay output. 3) Files changed. 4) What is left. 5) New parking-lot items.

   Done whenThe override gives the same results as the original from the same state, and all replays pass.

   Proof this works: Dissidia012-PC (matched C used as native overrides), Tag Force Recomp (TF_DECOMP_VERIFY runs both from the same state), https://github.com/nicolalol3/mhfu-decomp (non-matching C injected into the real program)

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

On Path A, one task is one missing system call, one crash or one drawing bug. Each ends with the bounded boot check or a replay. On Path B, one task is one function, checked by objdiff and the module hash. Keep the ledger as the list of units. Give each worker a slice, never the whole game.

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 `PROGRESS.md` at the start of every session.
- Never edit files in `generated/`. If generated code is wrong, fix the generator or the profile, then regenerate.
- Bound every game run with a time limit. Never leave the game running or drive it with an open-ended input loop.
- Path A: build with `cmake --build out --target <TARGET> -j2`, never `ninja` directly. Never delete `.ninja_deps` or `.ninja_log`.
- A boot is done only when `python tools/boot_check.py --no-interpreter` prints PASS.
- Trace the hardware; do not recall it. Never write GE register numbers, PSP structs or NID meanings from memory.
- A missing system call must stop the run with its name. Never return a fake success to move on.
- No game data in Git: no ISO, EBOOT, PRX, decrypted files, generated code or captures.
- `portablekit/` is read-only. Framework changes go in numbered patch files I approve.
- Path B: only `ninja` with `sha1sum -c` OK counts as a match. Never edit `config/*.sha1`, `asm/` or `tools/`.
- Path B: no inline asm except VFPU asm the original used, no `.word`, no `.incbin`, no data in `.text`.
- Never paste game disassembly into decomp.me or other public sites.
- In a worktree, use absolute paths and run builds only inside that worktree.
- Write side issues in `notes/parking-lot.md`. Write each result and dead end in `PROGRESS.md`.
- Do not copy code from `PPSSPP` into this repo. Read it as a reference only.

Keep the context small

• Give Claude an address and a log path, not pasted disassembly.
• Ask for one _TRACE_ switch at a time. Full traces of a hot module run for a long time and fill the context.
• Never let Claude open files in generated/. They are huge. Use dump_function for one function instead.
• Clear the chat after each fixed bug or matched function.
• Use a subagent to read a long Ghidra export and return a short summary.
• Keep CLAUDE.md short. Point to notes/compiler-quirks.md and the bring-up doc by topic.

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: Decide if <GAME> (<DISC_ID>) can be recompiled for PC, and which framework to use.
READ FIRST: `notes/disc-listing.txt`, the READMEs of `TeamGDB/PortableKit` and `jessicanataliagta/PSPRecomp`, the RecompLauncher PSP list.
FENCE: Edit only `SCOPE.md` and `notes/survey.md`. Write no code.
CHECK: `SCOPE.md` answers: is EBOOT.BIN encrypted, extra PRX modules, overlays, import count by library, VFPU use, prior work with URLs, framework pick with reasons, first milestone and its check.
BUDGET: Stop after 45 minutes.
IF BLOCKED: Stop. Say plainly what you cannot know without the disc or a test run.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Verdict: go, no-go or test first, with reasons. 3) Files changed. 4) Risks ranked. 5) New parking-lot items.

GOAL: Build `ledger/functions.csv` and `ledger/imports.md` from the Ghidra export of <GAME>.
READ FIRST: `SCOPE.md`, `<EXPORT_PATH>`, the `PPSSPP` `.sym` file at `<SYM_PATH>`.
FENCE: Edit only `ledger/`. The Ghidra project is read-only.
CHECK: Run `python tools/ledger_check.py`. Done means it prints OK and the function count equals the export's.
BUDGET: Stop after 60 minutes.
IF BLOCKED: Stop. Mark unsure rows as unknown. Do not invent names.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Counts: functions, SDK, middleware, imports, overlays. 3) Files changed. 4) What is left.

GOAL: Implement `<LIBRARY>::<FUNCTION>` so the boot passes it.
READ FIRST: `CLAUDE.md`, the boot log `<LOG_PATH>`, `ledger/imports.md`.
FENCE: Edit only the HLE files in `host/`. `portablekit/` and `generated/` are read-only.
CHECK: Run `python tools/boot_check.py --seconds 90`. Done means the log passes this call and earlier milestones still print.
BUDGET: Stop after 3 failed tries or 45 minutes.
IF BLOCKED: Stop. Do not fake a return value. Tell me what the game expects.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Log lines before and after. 3) Files changed. 4) The next stop.

GOAL: Make `<FUNCTION>` match exactly with <COMPILER> <FLAGS>.
READ FIRST: `asm/<MODULE>/<FUNCTION>.s`, `notes/compiler-quirks.md`.
FENCE: Edit only `src/<MODULE>/<FILE>.c`. No inline asm except original VFPU asm, no `.word`, no `#pragma` tricks.
CHECK: In WSL, run `ninja`. Done means objdiff 100% for `<FUNCTION>` and `sha1sum -c` OK.
BUDGET: 5 serious attempts. Save each in `try/<FUNCTION>/`.
IF BLOCKED: Stop. Save the best try in `wip/` with a note naming the differing instructions.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Score and sha1sum line. 3) Files changed. 4) Lesson, if general.

GOAL: Pick the next <N> units from `ledger/functions.csv` (or `ledger/bugs.md`) and start one worker per unit.
READ FIRST: `CLAUDE.md`, the ledger, `PROGRESS.md`.
FENCE: Edit only the status column of the ledger and `ledger/batches/`. Each worker gets its own worktree at an absolute path. Do not do unit work yourself.
CHECK: Each worker reports with the unit's check output. Done means every unit is marked matched, fixed, wip or blocked, with proof pasted.
BUDGET: At most <N> workers at once. Stop the batch if two workers break the build.
IF BLOCKED: Stop. Tell me which worker broke what and the last good commit.
OTHER PROBLEMS: Collect them in `notes/parking-lot.md`.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Table: unit, worker, result, proof line. 3) Ledger rows changed. 4) Next batch suggestion.

GOAL: Find the cause of <SYMPTOM> at <WHERE>. Do not fix it yet.
READ FIRST: `PROGRESS.md` dead ends, the log `<LOG_PATH>`, the capture `<CAPTURE_PATH>`.
FENCE: Read only, except new trace output under `out/traces/`. No code changes.
CHECK: Done means you name the cause and show trace lines or a `PPSSPP` comparison that prove it.
BUDGET: Stop after 60 minutes or 3 theories that fail.
IF BLOCKED: Stop. List each theory, the test you ran and what it showed.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The cause and its proof. 3) The fix you suggest and its risk. 4) Dead ends to record.

GOAL: Check that the work claimed in <BRANCH> is real.
READ FIRST: `CLAUDE.md`, the diff of <BRANCH> against main.
FENCE: Read only. Write only `notes/verify-<BRANCH>.md`.
CHECK: On a clean clone, run the full check: Path A `python tools/regress.py --no-interpreter`; Path B `python3 configure.py && ninja && python3 tools/gate.py`. Done means each claim is marked REAL or FAKE with proof.
BUDGET: Stop after 60 minutes.
IF BLOCKED: Stop. Say what you could not check.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Check output. 3) Look for: edited hashes, edited tools, edits in `generated/`, fake system call returns, interpreter left on, asm in sources, disabled tests. 4) Verdict per claim.

GOAL: Report project status from the ledger and logs only.
READ FIRST: `ledger/functions.csv`, `ledger/bugs.md`, `PROGRESS.md`, the last regression output.
FENCE: Read only. Write only `notes/status-<DATE>.md`.
CHECK: Every number in the report comes from a file or a command you ran. Name the source next to each number.
BUDGET: 15 minutes.
IF BLOCKED: Stop. Say which number you could not get.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) Counts: matched, wip, open bugs, replays passing, stages reached. 3) Change since last report. 4) Top three blockers. No prose padding.

GOAL: Write what the next session needs into the ledger files.
READ FIRST: `PROGRESS.md`, `git status`, `git log -5`.
FENCE: Edit only `PROGRESS.md` and the ledger status columns. No code changes.
CHECK: A new session can start from `PROGRESS.md` alone. It names the current unit, its state, the last check output, the next step and the dead ends.
BUDGET: 10 minutes.
IF BLOCKED: Stop. Say what state you could not confirm.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) The new `PROGRESS.md` section. 3) Uncommitted files and why.

GOAL: Give me a plain answer on <TASK>: can it be done, and how.
READ FIRST: Your notes on this task and `PROGRESS.md` dead ends.
FENCE: Read only. No more attempts.
CHECK: Done means you state one of: can do with <PLAN>, cannot do because <PROOF>, or unknown until <TEST>.
BUDGET: 10 minutes.
IF BLOCKED: Say unknown and name the one test that would tell.
REPORT: 1) DONE, PARTIAL or BLOCKED. 2) What cannot be done and why, with evidence. 3) Two or three options with cost in sessions. 4) Your pick.

GOAL: Ask me before you leave the fence for <TASK>.
READ FIRST: `SCOPE.md`, the task card you are on.
FENCE: Make no edits outside the fence while you wait.
CHECK: Done means I have your request with: the file or folder, the exact change, why the task needs it, and the risk.
BUDGET: 5 minutes to write the request.
IF BLOCKED: Park the task in `PROGRESS.md` and stop.
OTHER PROBLEMS: Write them in `notes/parking-lot.md`.
REPORT: 1) BLOCKED. 2) The request. 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 PortableKit or PSPRecomp already covers most system calls your game uses.
• How much code sits in overlays or extra modules.
• How much VFPU code and how many rare GE features the game uses.
• Your PC: the first full build can take hours and needs a lot of memory.
• For Path B: which compiler, how many functions, and how much is C++.

The facts behind these numbers

Projects reviewed (17)

We took the top-starred project for each of the top 12 PSP games on RecompLauncher. We added two more that used AI. The catalog has no working PSP decomp, so three Path B projects come from outside it.

What each project teaches

What we could not check

• How many hours a week any dated project spent. The time ranges assume 10 to 15.
• Earlier private history of Tag Force Recomp, God of War PSP, MHForever, Yakumo and Sims 2. Their first public commit may not be their start.
• Whether HST-Decomp's pace holds past 41%. No PSP game is fully decompiled.
• What Street Fighter Alpha 3 MAX was. Its repo returned 404.
• The current Vulkan SDK version. The LunarG page did not show it.
• PSP RAM and VRAM sizes. They were seen only in search snippets, so they are left out.
• Whether PortableKit builds a full port on Windows for a new game. Its CI tests the framework on Windows; Yakumo runs on Windows.
• Whether the <PREFIX>_STRICT_HLE and <PREFIX>_LIST_STUBS switches work the same in PSPRecomp. They come from the PortableKit docs.
• Stars for the three outside projects come from GitHub on 2026-11-13, not from the catalog.
• No command in this guide was run here. Each was checked against live docs or the review cards only.
• How to get SDL3 and FFmpeg for a PortableKit port on Windows. Its README gives install steps for macOS only.
• Whether a plain timeout works in Git Bash on Windows. Let tools/boot_check.py enforce the time limit itself.
• Whether stock binutils-mipsel-linux-gnu accepts -march=allegrex. The reviewed decomps use allegrex-as or a patched pspas instead.
• That ghidra-allegrex and GhidraMCP work together in one Ghidra 12.1.4 install. Both READMEs were read, but the pair was not run.
• PSPRECOMP_INTERPRETER_VERBOSE comes from the Dissidia012-PC card only. The PortableKit docs do not list it.
• A third PSP framework, Nakagawa Recomp by the HST-Decomp author, exists but was not reviewed for this guide.

Sources

• PortableKit README
• PortableKit: Bringing up a new game
• PortableKit: Building
• PortableKit: Writing a profile
• PortableKit Ghidra export script
• PSPRecomp profile guide
• PSPRecomp README
• AljandrOrtega PSP recompilation toolkit
• PPSSPP downloads
• PPSSPP docs: Allegrex overview
• PPSSPP docs: the GE
• PSP RE quick start guide
• ghidra-allegrex README
• ghidra-allegrex releases
• Ghidra 12.1.4 release
• GhidraMCP release 2.0
• Ghidra README
• pspdecrypt README
• splat README
• splat Quickstart
• spimdisasm README
• m2c README
• objdiff README
• wibo README
• mwccgap README
• decomp.me compiler kits
• decomp.me compilers release
• sotn-decomp Makefile (allegrex-as download)
• sotn-decomp release with allegrex-as
• Dissidia012-PC WSL setup script
• HST-Decomp project guide (setup in WSL)
• Install WSL (Microsoft Learn)
• Snowboard Kids 2 decomp: Claude Code hooks
• One-shot decompilation with Claude (Snowboard Kids 2)
• GhidraMCP README
• HST-Decomp README and AGENTS.md
• mhp2g-decomp configure.py
• mhp2g-decomp progress on decomp.dev
• sotn-decomp README
• sotn-decomp PSP progress on decomp.dev
• Tag Force 5 decomp README
• MHFU non-matching decomp README
• Yakumo AGENTS.md
• God of War PSP feasibility study
• Dissidia012-PC decomp getting started
• skills.sh: matching-decomp skill