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.