codecraft/server/resources/skills/recreate/SKILL.md

name, description

name	description
recreate	Re-create existing software (old DOS/Windows/Linux programs and games) as a new, modern implementation – project layout, unpacking, analysis, documentation, specification and a recreation proposal. Use for /recreate-init and /recreate-start.

Re-creating software

Goal: understand an existing program well enough to build a new, independent implementation that behaves like the original – on modern systems. We re-create, we do not copy: decompiled code is a source of understanding, never of code. Everything we build comes from the specification written in our own words.

Project layout

original/            the user's files: program, libraries, archives, installers (never modified, not committed)
original/extracted/  unpacked archives and installers (one folder per source file)
analysis/            tool output: binary_info, decompile results, notes (not committed)
docs/                documentation of the original (from the templates)
spec/                specification of the re-creation – the only input for building
proposal/            the recreation proposal
src/  tests/         the new implementation and comparison tests (later)

.gitignore must exclude original/ and analysis/ (third-party binaries and decompiled code stay out of the repository).

Phase 1 – Inventory and unpacking

1. List everything in original/ recursively with sizes (find original -type f -printf '%s %p\n') and identify each file with file.

2. Unpack every archive and installer without running it, each into original/extracted/<file name>/, then repeat on the results (archives inside archives, disk images, installers inside archives) until nothing is left to unpack:

   Found	Command
   zip, 7z, tar(.gz/.bz2/.xz), iso, img, NSIS installer, MSI, CAB, many self-extracting .exe	7z x -y -o<dir> <file>
   rar, lzh/lha, arj, sit, zoo and other old formats	unar -o <dir> -f <file> (or arj x, lha x)
   Inno Setup installer (file or innoextract -i says so)	innoextract -e -d <dir> <file>
   InstallShield (data1.cab + data1.hdr)	unshield -d <dir> x data1.cab
   Microsoft CAB	cabextract -d <dir> <file>
   MSI (if 7z gives no useful names)	msiextract -C <dir> <file>
   DOS executables packed with PKLITE/LZEXE/EXEPACK (see strings, binary_info)	note it – decompile the unpacked image if an unpacker is available, otherwise analyse behaviour and data files

   If a format cannot be unpacked, record it and continue – never execute installers.

3. Write docs/01-inventory.md (template): every file with origin (which archive), type, size, role guess (main program, overlay, library/driver, data, graphics, sound, music, configuration, save game, documentation).

Phase 2 – Analysis

1. binary_info for every executable and library: format (MZ/NE/PE/LE/ELF), CPU, compiler/linker hints, imports, strings.
2. decompile the main executable(s); for big programs start with max_functions and widen.
3. Explore the output with grep/read: entry point and main loop, initialisation, input, graphics (video modes, palettes, sprites), sound/music drivers, file I/O (which files are opened, how they are parsed), game/application logic, timing, configuration, save games.
4. Data files: identify formats (headers, magic numbers, xxd | head), match them with the loading code, decode them where possible (write small scripts in analysis/tools/).
5. Identify engines, libraries and middleware (strings, imports, copyright notices).
6. Keep working notes in analysis/notes.md. Ask the user (ask_user) when the purpose of something is unclear and they may know it.

Phase 3 – Documentation and specification

Fill the templates in docs/ (02–06) from the analysis – in your own words, with function addresses only as references. Then write spec/spec.md: the behaviour to re-create, screens and controls, rules/logic, data and file formats (byte layouts are facts and may be specified exactly for compatibility), timing, edge cases, and what counts as "done". The spec must be complete enough that someone who never saw the decompiled code could build the program from it.

Phase 4 – Proposal

Write proposal/recreation-plan.md (template): 2–3 technology options (e.g. Rust + SDL2, C++ + SDL, Godot, web/TypeScript) with fit, pros/cons and effort; the recommended option; architecture sketch; milestones (first playable/usable version first); how original assets are handled (loaded from the user's original files at runtime vs. new assets); comparison tests against the original; risks and open questions.

Then stop: summarise the findings and the recommendation for the user and ask with ask_user how to proceed. Do not start building before the user agrees.

Rules

• Never paste or mechanically translate decompiled code into src/. Names, structure and code are new. Facts needed for compatibility (file formats, constants, rules) are fine.
• Original assets (graphics, sounds, levels) stay the user's files: the re-creation may load them from original/ at runtime but does not copy them into the repository.
• Use todo_write for the phases; delegate broad searches through decompiled output to explore subagents to keep your own context small.