Richard ZinkandClaude Opus 5.5
a0d0e707f2
- Web Push (VAPID + RFC 8291, pure Rust): permission/question/finished notifications while no app window is visible; settings with test button - Guided new-session flow: task, craft target (website/app/game/old software/fresh), clean room or deep, description, model, folder (new, existing or cloned git repository); originals upload to original/ - Craft phase bar (craft_phase tool) for study/specify/build/check/ready - Chunked uploads (8 MB) up to server.max_upload_mb (default 500 MB) - All UI glyphs and emojis replaced by themeable SVG icons - Rename dialog with manual name or model-generated suggestion Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
93 lines
5.3 KiB
Markdown
93 lines
5.3 KiB
Markdown
---
|
||
name: recreate
|
||
description: 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.
|
||
- Report phases with craft_phase and use todo_write for the steps; delegate broad searches through decompiled output to
|
||
explore subagents to keep your own context small.
|