Read the request, project instructions, and existing issue record, including accepted choices, prerequisites, and evidence. Reuse settled framing.
Follow project conventions to consult relevant domain definitions, pending accepted changes, and system contracts. Resolve consequential conflicts; distinguish experimental assumptions from accepted meanings and implemented behavior. Missing conventions call for targeted clarification, not automatic project setup.
Establish question, scope/exclusions, scenarios, constraints, decision owner, stopping evidence, and the work it unblocks. Distinguish a measured fact from a preference requiring the owner's judgment.
Verify execution authorization, access, and representative inputs. A prepared brief alone does not authorize building or external writes. When implement runs a Prototype issue, that invocation authorizes building, committing, and pushing the dedicated branch.

Request	Action
Choice requires observing behavior	Prepare/run the bounded experiment within authorization
Only source evidence is missing	Return a research prerequisite rather than build a demonstration
Behavior already settled	Propose implementation; do not reopen design for ceremony
Preparation only, read-only mode, or unmet prerequisite	Retain the experiment brief and name what is pending

Done: question, stopping condition, owner, and execution scope established. Blocked: preserve the missing decision/evidence and continue only independent, authorized preparation.

2. Choose the environment and isolate the work

Inspect runtime, assets, inputs, components, and verification tools. Reuse the smallest environment preserving the behavior under test; isolated logic cannot establish real physics, rendering, device interaction, or production performance.
Before building, follow retention and handoff to establish the dedicated branch and preserve the prepared checkout.
Identify simulated data, temporary resources, and persistent effects. Isolate the experiment from ordinary use; preserve security and access controls.

Select only the procedures needed:

Question	Reference
Appearance, organization, interaction	Interface comparison
Rules, data shape, state transitions	Logic scenarios
Integration, physics, capacity, performance	Technical evidence

Done: representative environment, isolation, branch, and experimental limits clear. Unavailable tools or unsafe conditions remain blockers, not invented capabilities.

3. Build and exercise the experiment

Build only the accepted scope, with the minimum variants needed to answer the question. One model can suffice; comparisons need meaningful alternatives.
Record entry point, dependencies/configuration, initial data, actions, reset, expected observations, and limitations with the experiment.
Run startup, representative scenarios, reset/selection where relevant, and isolation checks yourself before presenting it.
Use focused tests or measurements when they protect the question. Neither a full production suite nor a blanket ban on tests is appropriate for every prototype.

Done: another person can repeat the demonstrated steps and inspect the evidence. Unresolved: observations are missing or inconclusive; name the gap rather than claim the question answered. Negative results are valid evidence.

4. Review the evidence and obtain the decision

Provide the runnable artifact or supported review surface and keep it available. Screenshots or video supplement interaction, not replace it when interaction is the question. Label simulation, assumptions, measured facts, and untested claims.
Present observations and trade-offs to the decision owner. Ask only for open judgments; do not ask the user to decide an already measured fact.
Record accepted/rejected behavior and remaining uncertainty against the reviewed version. Later changes require renewed validation of affected conclusions.

Done: the question is answered by evidence and any required judgment is accepted. Waiting: owner judgment remains open; preserve the artifact and resume point. A demonstrated failure may conclude the experiment without authorizing a new design.

5. Preserve and return

Follow retention and handoff for the reviewed commit, authorized remote publication, and updates to the existing Linear record.

Return the result, artifact/version, decision or unresolved question, limitations, and next action to implement or the originating task. Stop exploration at its evidence target. Product implementation needs its own request and ordinary verification; prototype approval does not establish production reliability. When implement ran the issue, return to it: it moves the issue to Done once the owner has validated the result and the reviewed commit is on the remote.

Done: evidence retained, required publication verified, and handoff usable. Pending: distinguish accepted decision, local artifact, remote availability, and tracker synchronization; name exact remaining operations instead of claiming completion.

prototype

Prototype a decision

1. Resume and bound the experiment