pokeheartgold: The AI Decomp Fork pret Publicly Disowned

By Indie Kings | October 16, 2026

Updated October 16, 2026: A fork of pret's pokeheartgold repository announces on its README that the Pokémon HeartGold and SoulSilver decompilation is complete, with every source file in C or C++ and both US Nintendo DS ROMs building byte-for-byte, per the fork's README which states the work was "Built with LLM agents." The human community project it forked wants no contact with it: the README opens with "Not affiliated with pret" and instructs contributors never to send its code upstream. This is a reverse-engineering research writeup; the repository ships no game data and building the ROMs requires your own legally obtained copies of the games.

Image: pokeheartgold fork repository card. Credit: GitHub, ctrl-cheeb-del.

The fork that says it finished

An AI-build fork of the pokeheartgold decompilation has done the work a human community spent years on, and the human project it forked asked to be kept out of it entirely.

Per the fork's README, the repository's status line is blunt: "Fully decompiled: everything's C/C++ and both ROMs build byte-for-byte. Built with LLM agents." That is the fork's own claim about its output, published on the same page that hosts the build instructions, not an independent measurement we can confirm from outside the repository.

The decompilation itself is a real discipline with a track record. It converts a game's compiled machine code back into readable C source, preserving the original compiler's exact output so the rebuilt ROM is identical at the byte level. pret's decompilation family treats a matched build as the finish line, and the fork's README uses the same vocabulary for its end state.

Per the same README, the repository also carries a source-language coverage treemap graphic, stored in the repository as docs/progress/treemap.svg, which visualizes how much of each game's code has been converted into C or C++. The graphic links onward to the project's progress reports inside the repository.

Byte-for-byte builds and the two ROMs

The README lists exactly two build outputs, both for the US Nintendo DS releases. Those sha1 values are the fork's published fingerprint of what its toolchain is supposed to produce from converted source.

Two claims are doing the work in that table and they are not the same claim. "Fully decompiled" says the converted source code covers the whole game. "Byte-for-byte" says compiling that source reproduces the original cartridges exactly. The fork's README asserts both in one sentence. We can verify the sentence exists; we cannot independently verify byte-for-byte from here, since doing so would mean building the ROMs and hashing them against original cartridges.

A matched build matters to this community because it proves the decompilation is faithful rather than merely plausible. If the C source recompiles to the identical hashes, every function has been recovered, not approximated. That standard is why a project of this size taking years is not a complaint about the humans who did the earlier work; it is the difficulty of the standard itself.

The pret boundary: keep everything here

The tension is stated in the README's first line: "Not affiliated with pret." The next sentence credits the origin, per the README: "This is a fork of pret's pokeheartgold repo, and the original tooling is all theirs."

Then comes the instruction that defines the whole project, quoted exactly, attributed as the fork's README: "pret doesn't accept AI-generated code and doesn't want to be associated with this, so don't send anything from here upstream or bother them about it; keep everything here."

Read plainly, the fork agrees to the quarantine. Its README tells contributors that pull requests aimed at pret's original repository are unwelcome and that the fork's output should stay on the fork. The README does not explain why the fork exists beyond the LLM agents line, and it does not claim any endorsement. The relationship it describes is one-way: the tooling lineage runs from pret's team, and the AI-built work product runs nowhere near them.

Indie Kings recently covered a decompilation platform that shut its index after conflicts over AI-generated forks, and this repository is the same dispute arrived at a working end state: the fork organizes itself around a policy answer an upstream community had already given.

Both sides have a coherent position and the README shows each one. pret's decompilation community has decades of norms about authorship, verification and contribution review, and its stated policy is that AI-generated code has no place upstream. The fork's README claims the goalpost project finished anyway, built with LLM agents, and asks nobody to argue about it. This article reports both statements as published and takes no side on which contribution policy is correct.

Where pret sits in the decompilation world

pret is the human-run umbrella project whose decompilation family includes the original pokeheartgold repository this one forks. Its best-known sibling project is the Pokémon Emerald decompilation, which turned the Game Boy Advance release into matched C source and became the template for decomp work across the series.

In that family, contribution is human-checked by design. Merged code is read, tested and matched against the original binary by maintainers, which is exactly the process the fork's README says excludes AI-generated code. The fork inherits the tooling, the build system and the goal standard from that community, then operates outside it by design, which is why the README's keep-it-here instruction is not a footnote but the fork's terms of existence.

Nintendo and The Pokémon Company hold the rights to HeartGold, SoulSilver and everything this research reconstructs, and neither has any role in either repository. This writeup covers the research activity only.

Scope: research, not a game download

This article is a reverse-engineering research writeup and nothing else. The repository builds two ROMs from decompiled source, but it ships no game data and no ROMs; per the fork's README, the build process requires your own copies of the games to supply the assets that the decompiled code wraps.

We describe that setup; we do not direct anyone to files. There is no download link in this article beyond the single repository README in Sources, no installation guide link, and no game dump or database site. Anyone wanting to reproduce the build would first need legally obtained copies of Pokémon HeartGold or SoulSilver on the Nintendo DS, per the README's setup expectations.

The repo's own description stays technical: fully decompiled C and C++ source, two matched build targets, a treemap of language coverage. Claims about the legality of decompilation projects generally are a long-running, unresolved argument we do not settle here, and this writeup offers no legal advice.

FAQ

What is this pokeheartgold repository?
Per its README, it is a fork of pret's pokeheartgold decompilation project that says it has fully converted Pokémon HeartGold and SoulSilver to C and C++ using LLM agents, with both US ROMs building byte-for-byte.

Does pret endorse the fork?
No. Per the fork's README, the project opens with "Not affiliated with pret" and says pret does not accept AI-generated code and does not want to be associated with the work.

Can I download the ROMs from the repository?
No. Per the fork's README, the repo builds ROMs from converted source but ships no game data or ROM files; a build needs your own legally obtained copies of the games.

Is the byte-for-byte claim verified?
Not by us. The claim is published on the fork's README alongside the two build-output sha1 values, and we cannot independently verify a matched build from outside the repository.

Why does the README tell people not to send code upstream?
Quoted exactly, the README says "pret doesn't accept AI-generated code and doesn't want to be associated with this, so don't send anything from here upstream or bother them about it; keep everything here."

What is the treemap graphic in the repository?
Per the README, the repository carries a source-language coverage treemap at docs/progress/treemap.svg showing how much of each game's code is converted to C or C++, linking onward to the project's progress reports.

Our take: This is a strange result: the fastest credible path to a fully matched decompilation may run through LLM agents, and it produced a finished artifact signed with a disclaimer telling its own contributors to stay away from the humans. We think the fork's restraint is doing real work here: it credits pret's tooling, quotes pret's policy accurately, and asks nobody to move code across the boundary either direction. The part worth watching is verification. "Built with LLM agents" plus "byte-for-byte" is a testable pair of claims, and the community standard that proves it is the same matched-build tooling pret built. If the hashes hold, the argument shifts from whether AI code belongs upstream to who certifies a matched build, and that argument has not started yet.

Bottom Line

The fork's README announces a complete HeartGold and SoulSilver decompilation in C and C++, two US ROM build targets with published sha1 values, and work performed with LLM agents, while also announcing its separation from pret in writing. Pret's original project is part of the family behind the Pokémon Emerald decompilation and treats matched builds as a human-reviewed standard. The fork ships no game data, so any build attempt starts with legally obtained copies of the games. The signal to watch from here is whether anyone outside the fork reproduces the hashes.

Sources

The fork's README, quote source for the disaffiliation statement, the byte-for-byte and LLM agents claim, the two build targets with sha1 values, the treemap reference, and the keep-it-here instruction: ctrl-cheeb-del/pokeheartgold README.