game-reverse-document

AlterLab GameForge -- Reverse Documentation

Most games start with passion, not paperwork. A prototype works, then grows, and weeks later nobody, including its author, can explain its architecture without reading every file. In 2026 add a new twist: much of that code was written by coding agents across dozens of sessions, each of which knew only what its prompt told it. The design lives in the code and in commit messages, nowhere else.

This workflow reads the code and writes the documents that should have existed: a design document in the language of game design, an architecture overview in the language of systems, a concept document that captures what the prototype is really about, or a one-page brief that lets a new teammate (human or agent) work safely on day one. It is not an API-doc generator.

Reverse documentation serves three needs: onboarding (hours of reading instead of weeks of archaeology), preservation (decisions captured before anyone forgets why), and diagnosis (systems that disagree become visible when documented side by side).

How this skill runs

This skill runs as a forked subagent: no conversation history, no questions to the user, read access to the repository plus git log/diff/show/status, and permission to write new documentation files. Therefore:

• Never ask. Choose the mode and scope with the rules below and list every assumption at the top of the document under "Assumptions and limits".
• Never edit code or existing documents. Write new files only. If the target file exists, write a dated sibling (...-2026-11-05.md) and note it.
• Finish with a summary message: mode, files written, systems documented, the three most important inconsistencies or gaps, and the count of UNVERIFIED items the team should confirm.

Resolving $ARGUMENTS