Prototype
Build a throwaway prototype that answers named unknowns, operate it, and hand it to the user for judgment.
Step 1: Name What the Prototype Must Settle
Take the open unknowns from what was passed in. When nothing was passed in, derive them from the current work: the questions whose answers in prose would still leave the user guessing, such as what a surface looks like or whether an interaction pattern makes sense in the hand.
State each unknown as a question the user answers by using the prototype rather than by reading a description. When the work that prompted the prototype already named competing alternatives, state the unknown as a comparison between them. Output that list as text before building, and keep anything outside it out of the prototype.
Step 2: Resolve the Prototype Path
Reuse the slug of the plan that governs the work when there is one. Honor an explicit slug or output path the user passed in. Otherwise generate a slug from the task title:
- Lowercase
- Replace non-alphanumeric characters with hyphens
- Collapse consecutive hyphens
- Trim leading and trailing hyphens
- Truncate to 40 characters at a word boundary
Write to .turbo/prototypes/<slug>.html, creating the directory when it does not exist. State the resolved path before writing. Later rounds of the same prototype rewrite that same file. When the path holds a prototype of a different subject, append -2, -3, and so on until the path is free.
Step 3: Build It
Write one self-contained .html file at the resolved path, with markup, styles, script, and sample data inline. It runs from file:// with no build step, no package install, and no dependency on the real application. Start the styles with [hidden] { display: none !important; }: an element whose own CSS sets any display value otherwise ignores the hidden attribute and paints anyway.
Build only what the Step 1 questions require. Hardcode the data behind them, stub anything that would cross a network boundary, and leave persistence out.
When a Step 1 question compares alternatives, build every alternative into the same file behind a header toggle, kept visually separate from the design as prototype chrome, so the user compares them in place rather than across descriptions. Label each position of the toggle by what the user will see or feel differ. When the user could not see or feel two alternatives differ, build one of them, leave the other out of the prototype, and say so when handing it over. Keep that chrome in normal document flow rather than position: sticky or fixed, where it covers the controls scrolled beneath it.