prototype

Prototype

Announce at start: "I'm using the humane:prototype skill to make this idea lookable and clickable at the cheapest fidelity that answers the question."

A prototype exists to answer exactly one open question — is this the right structure, does the navigation make sense, does the screen read at a glance — before anything expensive is committed. This skill produces the cheapest artifact that answers that question and stops.

Quick Reference

Need	Where
Format contracts per rung: file layout, hotspot markup, self-containment, the SVG text traps	references/formats.md
Where the output file goes	setup/references/paths.md — setup owns the path table
The editable design-file exit: availability, style archetypes, the active-document pre-flight	references/design-file.md

The one question

Every prototype names, before anything is drawn, the single question it will answer. A broad request ("mock up the app") contains several candidate questions — extract them, and ask the user to pick one; a prototype chasing two questions answers neither. Record the chosen question in the artifact's notes block (see Output).

The question is settled only by the user saying so, or by a named reviewer's output — a respondent-panel read, a walkthrough result. The maker's own impression that a structure "looks right" settles nothing; this skill never reviews its own output, and it does not certify its own handoffs either. Until the question is settled, it stays open, and escalation waits.

Where it sits

The home case is greenfield: after jtbd, before design-tokens. The corpus says what job the interface serves; the prototype proposes a structure for it; only a structure that survives being looked at or clicked through deserves a token set.

jtbd is preferred, not required. Entered directly, with no corpus: offer to run jtbd first, and if the user declines, proceed — with "no corpus; structure is a guess" stated in the artifact's notes block.