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: 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. ## When the gate passes, write the spec Include: flows and screens, all states (empty, loading, error, edge), components mapped to the design system by name, content and data requirements, and the analytics events that must ship with the build so the team can answer Gate 3 after launch: did it solve the pain and move the needle. If a `design-os.profile.yaml` is present, take the design-system reference and analytics event names from it instead of re-asking (see [templates/project-profile.schema.md](../../templates/project-profile.schema.md)). The validation signal is never a profile field, so the gate above still stands. ## Always include a Validation Record section Quote the evidence that earned the build: what was tested, with who