← All examples
Know your unknowns · Pre-implementation

Mock before you wire

Before Claude touches the real codebase, ask for a throwaway HTML mock — you'll find out what you actually want the moment you can click it, not three PRs later.

The prompt
Before wiring anything up, make a single HTML file mocking Acme's new frame-annotation toolbar with fake data. I want to react to the layout before you touch the real app.
What Claude produced
Acme · frame-annotation toolbar · mock, no real code touched

Floating pill, bottom-center. Hovers above the seekbar; hides on playback. Closest to what Loom/Frame.io ship.

Ridgeline '26 TEASER · CUT 04 1 2 3
00:00:41:07
PAUSED

Everything above is fake data in one static file — nothing reads from apps/player yet. Real wiring would live in apps/player/src/annotate/Toolbar.tsx behind the frame_annotations flag.

Open questions for you

Four layout calls I'd rather not guess

Tap a chip to record your pick — the reply template below fills itself in.

Q1Which placement should ship? The pill stays near the pointer but covers action in the lower third; the rail never occludes footage but is far from the seekbar; under-seekbar steals ~56px of player height.

Q2Color + stroke controls: always visible in the bar (what's mocked), or collapsed behind a popover on the active tool? Inline is one click faster; popover shrinks the pill by ~140px, which matters on 13″ laptops.

Q3The comment drawer currently overlays the right edge of the frame (open it via the Comments button). Should it instead push the video left so annotations are never covered while reading?

Q4Blur is the only tool that needs server-side rendering on export. Keep it in the v1 toolbar (with a "processing on export" badge), or hold it for v1.1 so the first release ships all-client-side?

My reactions — copy & paste back