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 unknow...

Security Scan

The skill's instructions, included references, and lack of installs or requested credentials are coherent with its stated purpose of auditing game prototype intent.

Purpose & Capability

The name and description describe auditing prototype intent; the SKILL.md and included reference documents provide exactly that guidance. There are no unrelated requirements (no binaries, env vars, or config paths) that would be inconsistent with the stated purpose.

Instruction Scope

Runtime instructions are limited to questions to ask, diagnosis steps, and reading bundled reference files. The skill does not instruct the agent to read arbitrary system files, access network endpoints, or exfiltrate data; it is conversational and document-driven.

Install Mechanism

This is an instruction-only skill with no install spec and no code files to write or execute. That minimizes disk and execution risk and matches the skill's described function.

Credentials

The skill requests no environment variables, credentials, or config paths. That is proportionate for a human-facing audit/instruction skill that simply guides questioning and evaluation.

Persistence & Privilege

always:false (default) and user-invocable:true. disable-model-invocation:false is the platform default for autonomous invocation; combined with the skill's minimal footprint this does not create an elevated privilege concern.

Assessment

This skill appears coherent and low-risk: it only provides audit questions and reads the included reference docs. Before using it, avoid pasting sensitive secrets or proprietary assets into prompts; if you plan to run it in an environment with strict policies, note that the agent can be invoked autonomously by default (a normal platform default) — you can restrict usage in your agent settings if you prefer manual invocation only.

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.