Reverse Documentation

This skill analyzes existing implementation (code, prototypes, systems) and generates appropriate design or architecture documentation. Use this when:

• You built a feature without writing a design doc first

• You inherited a codebase without documentation

• You prototyped a mechanic and need to formalize it

• You need to document "why" behind existing code

Workflow

1. Parse Arguments

Format: /reverse-document <type> <path>

Type options:

• design → Generate a game design document (GDD section)

• architecture → Generate an Architecture Decision Record (ADR)

• concept → Generate a concept document from prototype

Path: Directory or file to analyze

• src/gameplay/combat/ → All combat-related code

• src/core/event-system.cpp → Specific file

• prototypes/stealth-mech/ → Prototype directory

Examples:

/reverse-document design src/gameplay/magic-system /reverse-document architecture src/core/entity-component /reverse-document concept prototypes/vehicle-combat

2. Analyze Implementation

Read and understand the code/prototype:

For design docs (GDD):

• Identify mechanics, rules, formulas

• Extract gameplay values (damage, cooldowns, ranges)

• Find state machines, ability systems, progression

• Detect edge cases handled in code

• Map dependencies (what systems interact?)

For architecture docs (ADR):

• Identify patterns (ECS, singleton, observer, etc.)

• Understand technical decisions (threading, serialization, etc.)

• Map dependencies and coupling

• Assess performance characteristics

• Find constraints and trade-offs

For concept docs (prototype analysis):

• Identify core mechanic

• Extract emergent gameplay patterns

• Note what worked vs what didn't

• Find technical feasibility insights

• Document player fantasy / feel

3. Ask Clarifying Questions (Collaborative Protocol)

DO NOT just describe the code. ASK about intent:

Design questions:

• "I see a stamina system that depletes during combat. Was this for:

• Pacing (prevent spam)?

• Resource management (strategic depth)?

• Or something else?"

• "The stagger mechanic seems central. Is this a core pillar, or supporting feature?"

• "Damage scales exponentially with level. Intentional power fantasy, or needs rebalancing?"

Architecture questions:

• "You're using a service locator pattern. Was this chosen for:

• Testability (mock dependencies)?

• Decoupling (reduce hard references)?

• Or inherited from existing code?"

• "I see manual memory management instead of smart pointers. Performance requirement, or legacy?"

Concept questions:

• "The prototype emphasizes stealth over combat. Is that the intended pillar?"

• "Players seem to exploit the grappling hook for speed. Feature or bug?"

4. Present Findings

Before drafting, show what you discovered:

I've analyzed src/gameplay/combat/. Here's what I found:

MECHANICS IMPLEMENTED:

• 3-hit combo system with timing windows
• Guard-break mechanic (heavy attack vs blocking enemy)
• Stamina system (depletes on attack/dodge, regens when idle)
• Stagger system (builds up, triggers vulnerable state)

FORMULAS DISCOVERED:

• Damage = Base * (1 + StrengthScaling * Level)
• Stagger buildup = AttackStaggerValue / (Enemy.Poise * 0.5)
• Stamina cost = BaseStaminaCost * (1 - EfficiencyBonus)

UNCLEAR INTENT AREAS:

1. Stamina system — pacing or resource management?
2. Stagger — core pillar or supporting feature?
3. Damage scaling — power fantasy or needs tuning?

Before I draft the design doc, could you clarify these points?

Wait for user to clarify intent before drafting.

5. Draft Document Using Template

Based on type, use appropriate template:

Type Template Output Path

design

templates/design-doc-from-implementation.md

design/gdd/[system-name].md

architecture

templates/architecture-doc-from-code.md

docs/architecture/[decision-name].md

concept

templates/concept-doc-from-prototype.md

prototypes/[name]/CONCEPT.md or design/concepts/[name].md

Draft structure:

• Capture what exists (mechanics, patterns, implementation)

• Document why it exists (intent clarified with user)

• Identify what's missing (edge cases not handled, gaps in design)

• Flag follow-up work (balance tuning, missing features)

6. Show Draft and Request Approval

Collaborative protocol:

I've drafted the combat system design doc based on your code and clarifications.

[Show key sections: Overview, Mechanics, Formulas, Design Intent]

ADDITIONS I MADE:

• Documented stamina as "pacing mechanic" per your clarification
• Added edge cases not in code (what if stamina hits 0 mid-combo?)
• Flagged balance concern: exponential damage scaling at high levels

SECTIONS MARKED AS INCOMPLETE:

• "Enemy AI interaction with stagger" (not fully implemented yet)
• "Weapon variety and scaling" (only sword implemented so far)

May I write this to design/gdd/combat-system.md?

Wait for approval. User may request changes before writing.

7. Write Document with Metadata

When approved, write the file with special markers:

status: reverse-documented source: src/gameplay/combat/ date: 2026-02-13 verified-by: [User name]

Combat System Design

Note: This document was reverse-engineered from the existing implementation. It captures current behavior and clarified design intent. Some sections may be incomplete where implementation is partial or intent was unclear.

[Rest of document...]

8. Flag Follow-Up Work

After writing, suggest next steps:

✅ Written to design/gdd/combat-system.md

FOLLOW-UP RECOMMENDED:

1. Run /balance-check on combat formulas (exponential scaling concern)
2. Create ADR for stamina system architecture decision
3. Implement missing edge cases:
   • Stamina depletion mid-combo behavior
   • Stagger state during dodge
4. Extend design doc when weapon variety is implemented

Would you like me to tackle any of these now?

Template Selection Logic

If analyzing... Use template... Because...

src/gameplay/*

design-doc-from-implementation.md Gameplay mechanics → GDD

src/core/* , src/ai/*

architecture-doc-from-code.md Core systems → ADR

prototypes/*

concept-doc-from-prototype.md Experiments → concept doc

src/networking/*

architecture-doc-from-code.md Technical systems → ADR

src/ui/*

design-doc-from-implementation.md UI/UX → design spec

Example Session: Reverse-Document Combat Code

User: /reverse-document design src/gameplay/combat

Agent: I'll analyze your combat implementation to create a design doc. [Reads code, discovers mechanics, formulas]

Agent: I've analyzed src/gameplay/combat/. Here's what I found: [Shows mechanics, formulas, unclear areas]

   Before drafting, could you clarify:
   1. Stamina system intent?
   2. Is stagger a core pillar?
   3. Damage scaling — intentional or needs tuning?

User: 1. Stamina is for pacing, prevent button mashing 2. Stagger is core — I want deliberate combat 3. Yeah, exponential is too much, should be linear

Agent: Perfect, that clarifies the vision. Let me draft the design doc. [Shows draft with clarified intent]

   May I write this to design/gdd/combat-system.md?

User: Yes, write it.

Agent: ✅ Written to design/gdd/combat-system.md ✅ Marked as [REVERSE-DOCUMENTED] ✅ Flagged damage scaling for rebalancing

   Next steps:
   - Update damage formula to linear scaling
   - Run /balance-check to validate progression curve
   - Document stagger as core pillar in game-pillars.md

Collaborative Protocol

This skill follows the collaborative design principle:

• Analyze First: Read code, understand implementation

• Question Intent: Ask about "why", not just "what"

• Present Findings: Show discoveries, highlight unclear areas

• User Clarifies: Separate intent from accidents

• Draft Document: Create doc based on reality + intent

• Show Draft: Display key sections, explain additions

• Get Approval: "May I write to [filepath]?"

• Flag Follow-Up: Suggest related work, don't auto-execute

Never assume intent. Always ask before documenting "why".