AlterLab GameForge -- Reverse Documentation Workflow

Most game projects start with passion, not paperwork. A developer prototypes, iterates, and builds. Weeks later, the codebase works but nobody -- including the original author -- can explain its architecture without reading every file. There is no design document because the design emerged from code. There is no architecture decision record because decisions were made in the moment and never written down. This is the normal state of indie development, and pretending otherwise is dishonest.

This workflow reverses the traditional documentation flow. Instead of document-then-build, it reads existing code and produces the documentation that should have existed from the start. The output is not auto-generated API docs -- it is human-readable design documentation that captures intent, architecture, and game systems in the language of game development, not the language of code.

Reverse documentation serves three critical needs: onboarding (a new team member understands the project in hours, not weeks of code archaeology), preservation (the original developer's decisions are captured before they forget why), and diagnosis (inconsistencies between systems become visible when documented side by side).

Purpose & Triggers

Use this workflow when:

• A prototype works but has zero documentation
• A new team member needs to understand an existing codebase
• The original developer is leaving and knowledge must be transferred
• The project has grown complex enough that the author loses track of systems
• Someone says "document this" or "what does this code do?"
• A game jam prototype is being promoted to a full project and needs formal docs
• An existing project needs a design document for publishers, investors, or team alignment