Game Design Prototype Intent Audit

---

name: game-design-prototype-intent-audit description: 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.

---

Game Design Prototype Intent Audit

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.