prototype-to-speclisted

# Prototype to Spec A prototype earns a spec. This skill enforces the earning. ## The gate, before any spec Ask for the validation signal: the evidence that this prototype, among the directions explored, deserves to be built. Acceptable signals: usability findings, behavioral data from a prototype test, or measured performance against criteria the team set before generating. Not acceptable: "the stakeholder liked it," "it was the best looking one," or no answer. If there is no signal, stop. Do not write the spec. Instead, return the smallest test that would generate a signal — `validation-plan` designs it: who to put the prototype in front of, what to ask or measure, and what result would justify the build. That answer is the skill doing its job, not the skill failing. **The one exception: an owned bet.** Sometimes the build proceeds without evidence on purpose — a contract commitment, a compliance deadline, a strategic call. That is legitimate only when someone owns it explicitly: a named human with the authority, an acknowledgment that no validation signal exists, the reason, and a review date with the evidence that will judge the bet (see the bet block in [templates/work-ledger.schema.md](../../templates/work-ledger.schema.md)). Given all four, write the spec — and the Validation Record becomes a **Bet Record** stating plainly that there is no validation signal, quoting the bet verbatim, and carrying the review date forward so `outcome-readout` scores the bet on its o