For a direct invocation, use shared/references/model-preview.md to choose the branch first. Coordinator work and deterministic commands proceed within invocation authority. An actual worker branch uses one approved route snapshot. Nested calls reuse it without route selection or added workers.
Answer one decision-changing question with throwaway code. Prototype code never graduates: the next production task rebuilds the selected behavior under its acceptance contract. A prototype produces evidence and a decision, not a finished feature.
1. State the question
Identify the unknown, the observation that would answer it, and the time or scope limit. Read existing code and docs first. A question already answered by those sources does not need a prototype.
Choose the smallest useful form:
- Visual decision: read
references/ui.md. Start with one fixture or static screen for one question. When a comparison can change the decision, use two alternatives. An explicit user request for a different bounded set controls. Use a host page or switcher only when real app context changes the observation. - Logic or state behavior that a person must explore: read
references/logic.md. Use a standalone HTML demo. - A technical property such as integration behavior, latency, or library support: write a small local script or harness that records the relevant input, output, and measurement. Do not add a UI that cannot help answer the question.
2. Run the experiment
Keep the work isolated in a scratch location or local worktree. Name it as a prototype and give one command or file path to run it. Use safe memory backed or scratch data. Use real services only when that access is authorized and necessary to the question.
Skip production scaffolding and unrelated polish. Keep enough checks and error output to trust the experiment. Record actual observations and failed attempts. Stop at the agreed limit if the question remains unresolved.
3. Return the decision
Return these four fields:
question: the single question tested.answer: the decision, evidence, limitations, and any unresolved result.snippets: only decision-bearing state, schema, or type shapes; no production-ready claim.disposition: the artifact path and whether it is retained or removed. No prototype code is promoted to production.
Save the evidence beside the caller's decision record or task plan, with its decision revision or content hash. A later decision change marks the affected prototype superseded. For a visual decision, record an actual browser review before claiming the layout is verified; model or DOM checks do not prove visual usability. If browser review is unavailable, retain that open limit rather than claiming acceptance. Keep a local artifact when useful; commit a throwaway branch or update a tracker only when authorized. Do not delete unrelated files during cleanup.
Return to interview-me to settle its question, or to coding-design-plan to revise the slice plan. An unresolved result returns an open decision rather than a fabricated answer. This closes the prototype's acceptance contract.