Game Design Prototype Intent Audit

Audit a game feature, system concept, prototype plan, or preproduction proposal to determine whether the prototype is meant to sell the idea or reveal unknowns, and whether the prototype scope matches that intent. Use when teams are unclear about why they are prototyping, when a prototype risks becoming a demo in disguise, or when precious prototype time may be spent proving known strengths instead of testing real uncertainties.

Decide what the prototype is for before deciding what the prototype should contain.

Use this skill to audit whether a prototype is being built to convince stakeholders that an idea works, or to reveal the least-understood parts of the design. These two goals require different prototype choices. Confusing them is one of the most common ways to waste prototype time.

Read references/prototype-modes.md when classifying the prototype intent. Read references/unknowns-checklist.md when identifying what a learning prototype should target. Read references/failure-patterns.md when diagnosing common prototype mistakes.

What to produce

Produce:

1. Prototype read - what is being prototyped and why
2. Intent diagnosis - whether this is a selling demo, a learning prototype, or a confused hybrid
3. Scope fit - whether the prototype contents match the stated intent
4. Unknowns coverage - what the prototype is or is not actually testing
5. Risk diagnosis - what time or learning may be wasted under the current plan
6. Recommendation - what to prototype instead, emphasize, cut, or sequence differently

Process

1. Clarify the prototype ask

Ask:

• what idea, feature, or concept is being prototyped?
• who is the prototype for?
• what decision is the prototype supposed to unlock?
• what would count as success for the prototype itself?

2. Diagnose intent

The prototype usually serves one dominant purpose:

• Selling demo - prove the concept is exciting, legible, or worth greenlighting
• Learning prototype - reveal unknowns and answer risky design questions
• Confused hybrid - trying to sell the idea while also pretending to test unknowns, without doing either well

3. Check scope fit

Ask whether the implementation focus matches the intent. For example:

• selling demos usually emphasize strengths, clarity, and presentability
• learning prototypes should target unclear, risky, or least-understood aspects

4. Audit unknowns

If the team claims the prototype is for learning, identify:

• what specific unknowns are being tested
• whether the prototype can actually answer them
• what it is avoiding or glossing over

5. Diagnose failure mode

Common failures include:

• demo dressed up as learning
• prototype solving the easiest part, not the riskiest part
• too much polish hiding too little insight
• trying to answer too many questions at once
• building broad slices when one narrow uncertainty should be isolated

6. Recommend a better prototype move

Possible recommendations:

• turn it honestly into a selling demo
• strip it down into a learning prototype
• split one prototype into two sequential prototypes
• narrow the question set
• focus on the riskiest unknown first

Response structure

Prototype Read

• ...

Intent Diagnosis

• ...

Scope Fit

• ...

Unknowns Coverage

• ...

Risk Diagnosis

• ...

Recommendation

• ...

Fast mode

• Who is this prototype for?
• Is it trying to sell the idea or learn something?
• What unknowns are actually being tested?
• What is being polished that does not answer the real question?
• What is the better prototype plan?

Style rules

• Be explicit about the dominant intent.
• Do not flatter vague prototype plans.
• Prefer one answered question over many implied ones.
• If the prototype is really a demo, say so cleanly.
• If the prototype is not testing the true risk, point that out directly.

Working principle

A prototype is not automatically useful because it exists. Its value comes from whether it is built for the right purpose and judged by the right standard.