菜单
Guide prototyping for solo game dev. Use when deciding what to prototype, scoping a prototype, evaluating results, or deciding whether to kill or commit. Prevents both over-investment in prototypes and skipping prototyping entirely.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | prototype-coach |
| description | Guide prototyping for solo game dev. Use when deciding what to prototype, scoping a prototype, evaluating results, or deciding whether to kill or commit. Prevents both over-investment in prototypes and skipping prototyping entirely. |
| zones | {"knowledge":10,"process":30,"constraint":25,"wisdom":35} |
A prototype's job is to die so your game can live.
Invariant A prototype exists to answer a question, not to become the game. Set the question before building. Discard after answering.
Example Question: "Does grappling hook movement feel fun in 2D?" Build: 1 day. A square, a line, a circle to grapple to. No art, no sound, no menus. Answer: "Yes, the swing arc feels great when momentum carries." The prototype dies. The finding lives in the GDD. //BOUNDARY: Vertical slices are the exception — they DO become the game's foundation. But even vertical slices are built AFTER mechanic prototypes have validated the core.
Depth
Invariant Define how you'll know the prototype failed BEFORE you build it. If you can't articulate failure conditions, you'll never kill it.
Example "If after 2 days, the movement doesn't feel fun with just keyboard input (no polish, no juice), the mechanic is wrong for this game." This is a kill criterion. Without it, you spend day 3-7 adding polish hoping it will "feel better." //BOUNDARY: Kill criteria should be about feel and function, not about polish. "It doesn't look good" is not a kill criterion for a mechanic prototype — it has no art. "It doesn't feel responsive" IS a kill criterion.
Answers: "Does this game mechanic feel fun/interesting?"
Answers: "Can I create this art style at an acceptable quality level?"
Answers: "Can the engine/hardware handle this?"
Answers: "Does the full experience work together?"
Important: Only build a vertical slice AFTER mechanic prototypes confirm the core is fun.
archive/prototypes/ folder — but don't keep building on it.| Trap | Symptom | Intervention |
|---|---|---|
| Polish creep | Adding juice, effects, menus to a mechanic test | "Is the question answered? Then stop. Polish belongs in the real game." |
| New prototype shiny | Starting prototype 2 before evaluating prototype 1 | "Evaluate first. Write the findings. Then decide if a new prototype is needed." |
| Can't kill it | Extending time box because "it's almost there" | "You set kill criteria for a reason. What did they say?" |
| Perfectionism | Rewriting prototype code to be "cleaner" | "This code is supposed to die. Ugly is correct." |
| Scope expansion | "While testing combat, I'll also add inventory" | "One question per prototype. Inventory is a different question." |
When the user wants to prototype:
During prototyping:
After prototyping:
gdd-writer skill — Prototypes validate GDD hypothesesscope-guardian skill — Prototypes reveal true scopedecision-journal skill — Prototype outcomes are decisionssprint-manager skill — Prototypes are Spike ticketsBuild it fast. Answer the question. Kill it with gratitude.
Declare what the system should be before writing code. Use when building new features, redesigning feature areas, or making significant changes that need a declaration of intent. Guides the declaration chain from findings through plans.
Wear the QA hat — think about quality the way a 15-year senior QA thinks. Use when building features, reviewing work, validating output, or when anything feels "done" but hasn't been proven to work. Prevents the gap between "it runs" and "it works."
Evidence-first research with mandatory citations and source evaluation. Use when gathering information for decisions, comparing approaches, investigating unknowns, or any task requiring verified evidence from multiple sources. Invoke at the START of research, not when writing up results.
Check and invoke available skills before starting work. Invoke at the start of any task to ensure relevant skills are loaded.
Effective Mermaid diagrams. Use when creating markdown documents with human audiences.
Guides effective documentation creation. Activates relevant guidance for north-star, gestalt, reference, research, design, plan, flow, findings, concepts, or process documents. Prevents cascading harm from wrong information.