FAQ

Open GDD is a public 13-chapter structure and writing template. A real GDD is your project-specific version: decisions made, numbers filled, reviewable and executable.

Yes—treat it as downstream acceleration. Use Open GDD to lock key decisions first, then let AI implement and expand within those constraints. Vibe coding without an upstream spec is what creates the "vibe coding crisis".

Start with chapters that set direction and scope: core loop, audience/platform, progression/economy, content/levels, then tech and production planning. Keep each chapter at "minimum reviewable detail".

Give your idea and constraints, and ask the agent to fill one chapter at a time. Require concrete examples, numbers, and tables where relevant. Review diffs chapter-by-chapter to prevent long-form hallucination.

Use chapter slugs as citations in prompts: "only follow /docs/{slug} constraints." Convert each chapter into executable tasks: data schemas, rules, UI requirements, asset lists, and integration contracts.

Both. Studios get alignment and handoff; indies get focus and less rework. For small games, mark non-essential chapters as N/A or "later".

No. Write just enough to ship a first playable, then expand as you validate. The point is to keep a clear upstream reference for every iteration.

Not if it’s chaptered. Open GDD is structure: fill the minimum, cite chapters in prompts, and review changes as diffs to reduce token cost and rework.