Build a Working Prototype + Companion Doc

Show a working prototype instead of writing a PRD first. A prototype with a companion doc reaches the same understanding faster and produces a better conversation — engineers start asking "how do we make this better?" instead of "what do you want?". The non-negotiable bar: 80% of the way there with zero engineering time, and it must not crash on the first click.

When to Use

• Validating a solution's interaction or flow, where a static mock is not enough
• Giving an identify-test-assumptions desirability/usability LoFA a concrete test method
• Turning the engineering conversation from "what do you want?" into "how do we make this better?"
• Branch vs generate-figma-prompt: clickable flow → prototype; static visual exploration → Figma

Input — specify the outcome before the prompt

A vague prompt yields a vague prototype. Before writing a single character of the build prompt, write down three things and paste them as the first message:

• Input — what data source or user input is needed
• Output — concretely, what the finished artifact shows
• Audience — who looks at it and what decision they are trying to make