game-design-reviewlisted

# Game Design Review Review a design by tracing how rules and presentation are likely to shape player decisions and experience. Treat the review as a decision aid, not a universal checklist or a substitute for playtesting. ## Responsibility boundary - Use this skill when a design object or decision already exists and needs examination. - This skill is self-contained. Do not assume any other skill, workflow, repository layout, document set, or game engine exists. - When the user needs a new formal design document rather than a review, return the clarified direction, constraints, open questions, and validation criteria needed to author it. - Do not convert a design recommendation directly into code structure, engine APIs, or implementation tasks. ## Review modes Every review shares the same spine: 1. **Name the review object.** The whole game, one loop, one mechanic, a level, an interface flow, a narrative beat, a social feature, or a production choice. 2. **State the decision at stake.** A choice or testable question; if none exists, the most consequential unresolved assumption. 3. **Build an evidence baseline.** Audience, rules, constraints, prototype behavior, and playtest observations, separating repeated patterns from anecdotes; mark each material statement as `confirmed`, `assumed`, or `unknown`. 4. **Close the review.** Prioritized findings, the smallest useful intervention, and a validation experiment. The modes differ in how the examination between these ends is