sm64ds-decomp: Skill for Claude Code

Translation-unit slicing

The linker erased the original .cpp boundaries; tools/tu_map.py reads them back out. Full derivation and limits: notes/tu-boundaries.md. To execute a merge and verify it, use decomp-tu-build — this skill is about reading the map, not acting on it.

0. Regenerate the map, in this order

python tools/rtti_extract.py     # -> build/rtti.json
python tools/rtti_vtables.py     # -> build/rtti_vtables.json
python tools/tu_map.py           # -> build/tu_map.json

build/ is gitignored, so a fresh worktree has none of this.

Nothing enforces that order, and skipping it fails silently. vtable_labels() returns {} when build/rtti_vtables.json is absent, and tu_map.py then writes a complete, self-consistent, wrong map and exits 0. Measured on main from an empty build/:

	full chain	rtti_vtables.json absent
whole-ROM TUs	532	516
boundaries	{low: 68, medium: 110, high: 280}	{low: 72, medium: 124, high: 246}
TUs with a class	400/532	370/516
under-segmented	ov007, main, ov075, ov084	ov007, main, ov005, ov084
ov080	5 TUs, 4 classed	6 TUs, 4 classed
--check	all gates PASS, exit 0	all gates PASS, exit 0

The known-answer gate asserts ov080's classed TU count, which is 4 either way, so it passes for the wrong reason. The under-segmented list is itself a casualty, so you cannot use it to detect the problem either. The one visible tell is the negative-control table, which collapses to blind 1 / blind-classed 0. There is no exit code to lean on: check the prerequisites yourself.

--blind is not an opt-out — it is the negative control, dropping the mangled-name signal to score what RTTI alone recovers. The whole flag set is --module, --verbose, --check, --blind, --split-swallowers [K], --out; nothing suppresses the RTTI labels while keeping the names. tubuild.py regenerates the map only when it is entirely absent — a stale-but-present map is reported as a note and used as-is.