design-system

To write a dependency-aware game design document, this Skill guides you through each required section step by step, pulling in existing game concepts and dependency contracts to prevent contradictions and missing cross-references.

A comprehensive game system GDD requires specific sections: Overview, Player Fantasy, Detailed Design and Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, and Acceptance Criteria. Structuring documentation with these sections ensures complete system design coverage and technical feasibility validation.

You can safely update existing game design documents using a retrofit mode that fills only missing or placeholder sections. This prevents overwriting existing content while still validating the new additions against registry facts and upstream dependency interfaces.

You validate new game system designs by checking them against game concepts, registry facts, and technical ADR constraints during documentation. This context-aware design process surfaces cross-system feasibility conflicts and registry mismatches before implementation begins.

The best way to structure acceptance criteria and tuning knobs is to include them as dedicated sections within a standardized GDD template. Capturing these parameters during the guided documentation process ensures systems are testable and easily adjustable during game balancing.

You need a systems index file like design/gdd/systems-index.md when performing retrofit filling for existing systems. For new system design, the guided authoring process reads the game concept and systems index to avoid contradictions and respect upstream interfaces.