game-prd-builder

name	game-prd-builder
description	Use when turning a game concept, prototype, or brainstorm into a production-ready PRD for a video game, especially for systemic games that need core-loop definition, progression, replayability, balance constraints, MVP scope, content pipelines, or expansion hooks.

Game PRD Builder

Overview

Turn game ideas into implementable PRDs. Preserve the user's non-negotiable core rules, then expand them into systems, constraints, and production-ready scope.

Workflow

1. Lock the immutable core first.
   • Separate fixed rules from expandable systems.
   • Treat user-stated foundation rules as hard constraints unless they explicitly approve changes.
2. Translate ideas into codeable systems.
   • For each mechanic, define trigger, state, resolution, player decision, failure case, and tuning knobs.
   • Reject vague design language that cannot be implemented or balanced.
3. Build the document from top to bottom.
   • Cover product overview, design goals, target players, run structure, core loop, immutable rules, major systems, UX feedback, balance risks, MVP scope, and milestones.
4. Write game-specific sections that generic PRDs often miss.
   • Include build identity, replayability, run length targets, risk-versus-stability decisions, meta progression, difficulty layers, and future expansion hooks.
   • If the design should be theme-agnostic, separate system semantics from content skinning.
5. Validate before finalizing.
   • Remove flavor-only sections with no gameplay consequence.
   • Flag infinite scaling, dominant strategies, unwinnable states, and systems that are too broad for MVP.

Output Rules

• Preserve the user's fixed gameplay foundation.
• Prefer system interactions over isolated feature lists.
• Use requirement language that can be implemented, tested, and balanced.
• Explicitly mark in-scope, out-of-scope, and future-extension sections.
• State unresolved decisions instead of hiding them.

Reference Use

• Read references/prd-template.md to structure the final document.
• Read references/design-checklist.md before finalizing to catch common gaps.

Common Failure Modes

• Writing a software-product PRD instead of a game-systems PRD.
• Replacing the user's fixed rules with a cleaner but different game.
• Describing mechanics as fantasy without triggers, states, and constraints.
• Skipping balance risks, anti-patterns, and failure states.
• Letting future-content ideas bloat the MVP.

Example Trigger

Use $game-prd-builder to turn this roguelike board-building concept into a full PRD without changing the immutable core loop.