game-reverse-document

Generates design, architecture, and concept documentation from existing game codebases.

Updated Aug 11, 2026
One-click install
npx skills add https://github.com/zerox-core/AI_Game --skill game-reverse-document-zerox-core
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: game-reverse-document
Source: https://github.com/zerox-core/AI_Game/tree/main/.continue/skills/game-reverse-document
Command: npx skills add https://github.com/zerox-core/AI_Game --skill game-reverse-document-zerox-core

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Game prototypes often ship working code with zero documentation, leaving teams unable to explain architecture, onboard new members, or preserve design intent. This Skill reverses the traditional document-then-build flow by scanning an existing codebase and producing the human-readable design documentation that should have existed from the start. ## Core Features & Use Cases - System Detection and Mechanics Extraction: Scans code for fingerprints of movement, combat, inventory, UI, audio, save, AI, and other game systems, then extracts mechanics, tunable parameters, and design intent with VERIFIED/INFERRED/UNVERIFIED confidence markers. - Three Output Modes: Produces a reverse-engineered Game Design Document (design mode), an Architecture Decision Record with dependency maps and technical debt registers (architecture mode), or a game concept document extracted from a playable prototype (concept mode). - Dependency and Inconsistency Mapping: Maps cross-system dependencies, flags circular dependencies, orphaned code, missing systems, and contradictions between systems instead of hiding them. - Use Case: A game jam prototype is being promoted to a full project. Run the workflow in concept mode to extract the core loop, mechanics, scope assessment, and gaps, producing a concept document that guides full development. ## Quick Start Ask the assistant to document the existing game project at the repository root and generate a reverse-engineered design document from the code.

Frequently Asked Questions about game-reverse-document

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a design document from existing game code?

Run the workflow in design mode against your project path. It scans the codebase, detects game systems like movement, combat, and inventory, extracts mechanics and tunable parameters, and produces a reverse-engineered Game Design Document organized by system rather than file structure.

What game engines does reverse documentation support?

The scan detects Godot via project.godot and .gd files, Unity via .unity files and ProjectSettings, Unreal via .uproject files, web frameworks via package.json, and Rust via Cargo.toml. Projects without these markers are treated as custom engines.

Can I document only one module instead of the whole project?

Yes. Pass a specific path as the argument instead of scanning the full project. Running architecture mode on a single module maps its internal structure, dependencies, and coupling points, which is useful before refactoring.

How does it handle code whose intent is unclear?

Ambiguous intent is marked with [UNVERIFIED] tags and flagged for the developer to clarify, rather than guessing. Mechanics are labeled VERIFIED, INFERRED, or UNVERIFIED so readers know which claims trace directly to code evidence.

What is the difference between design, architecture, and concept modes?

All three share the same code analysis pipeline but differ in output. Design mode produces a Game Design Document, architecture mode produces an Architecture Decision Record with dependency maps and technical debt, and concept mode produces a pitch-style concept document from a playable prototype.

When should I not use reverse documentation?

Do not use it to write new design documents from scratch before any code exists; that belongs to brainstorming or design-review workflows. It reads existing code, so it cannot document systems that have not been implemented yet.