Stanestane 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:
- Prototype read - what is being prototyped and why
- Intent diagnosis - whether this is a selling demo, a learning prototype, or a confused hybrid
- Scope fit - whether the prototype contents match the stated intent
- Unknowns coverage - what the prototype is or is not actually testing
- Risk diagnosis - what time or learning may be wasted under the current plan
- 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.