Prototype the riskiest assumption first

The start of a project or feature, and any time you're deciding what to build next under uncertainty. Prioritize by "what's most likely to be wrong and most catastrophic if it is?"

Risk is cheapest to retire early. The assumption that "the core is fun," "this control scheme works," "players will understand this mechanic," or "this tech is feasible" is a loaded gun pointed at the project — and the longer it stays untested, the more you build on top of a maybe [S-proto-vertical-slice]. Prototyping the safe parts first feels productive but defers the decisions that actually determine whether the project should continue. Attacking the riskiest question first means you either de-risk it (and proceed with confidence) or discover the problem while a pivot costs days instead of months. Fail fast on the things most likely to fail.

List the project's core assumptions and rank them by (likelihood of being wrong) × (cost if wrong). Build the cheapest experiment that resolves the top one. Prefer answering "will this even work?" before "how good can we make it?" Reassess the risk ranking after each prototype — retiring one risk often promotes another.

Little in principle. The practical debate is how to weigh technical risk vs. design/fun risk first when both loom — usually the fun/design risk is primary for a game (a technically perfect un-fun game is still dead), but a project resting on unproven tech may need to retire that first.

The prioritization rule that makes "find the fun first" (PROTO-0001) actionable — of all the things to prototype, do the scariest. Pairs with early testing (PLAYTEST-0002). Confidence 4.