The useful idea here is older than Claude and cheaper than it has ever been: when a design argument won’t resolve, stop describing and start showing.
A prototype is throwaway code that answers a question. The question decides what gets built — and what gets ignored. No error handling, no tests, no persistence, unless the question is about error handling, tests or persistence.
When it earns its place
- You can’t tell whether a flow feels right until you click it.
- The data looks fine on a whiteboard and you suspect it isn’t.
- There are three plausible layouts and everyone has an opinion.
Asking for options A / B / C is the strongest move. Reacting to something concrete is far easier than specifying it from a blank page, especially for colleagues who don’t write code and have been asked “so what do you want it to look like?”
Worth knowing
- Delete it. The whole value is that it’s disposable. A prototype that quietly becomes production is the most expensive thing on this page.
- Say what the question is. “Build me a prototype” without a question produces a small unfocused app. “Prototype whether one-click approval is confusing” produces an answer.
- Pairs with show, don’t describe and the Level up step on the use cases — same instinct, applied to a whole build.
- Installing gives you the whole set —
/teach,/handoffand/grill-mearrive in the same .
Access
Public — no access request needed. It ships in ’s official marketplace, so there is no marketplace add step.