Prototype Lab
A prototype answers one question. It is not production code with fewer tests.
Pick The Prototype Question
Choose the branch:
- Logic prototype: state model, workflow, parser, scoring, queue, rules, or business logic.
- UI prototype: layout direction, interaction model, variants, motion, or product feel.
- Integration prototype: unknown API/tool behavior, deployment constraint, or browser capability.
If ambiguous, state the assumption and keep the artifact easy to delete.
Rules
- Mark it as prototype/throwaway in path, UI, comments, or README.
- Use one command to run.
- Keep state in memory unless persistence is the thing being tested.
- Avoid broad abstractions, production plumbing, and hidden dependencies.
- Surface state after actions so learning is visible.
- Do not leave prototype code mixed with production code without a decision.
UI Variant Pattern
When exploring design, create 2-4 meaningfully different variants. Let the user switch via route, query param, segmented control, or small debug toolbar. Do not make tiny color-only variations.
Logic Pattern
When exploring state, make a terminal or local web harness that can run scripted cases and manual interactions. Print current state, event, output, and invariant violations.
Closeout
When the prototype answers the question:
- capture the decision in an issue, ADR, notes file, commit message, or final report;
- delete the prototype or identify exactly what will be absorbed into production;
- list what remains unproven.
1---2name: prototype-lab3description: Build throwaway prototypes to answer a specific product, UI, state-machine, data-model, or workflow question before committing production code. Use when the user asks to prototype, explore variants, sanity-check logic, try designs, make a playable mock, or learn quickly with code that will be deleted or absorbed.4license: MIT5---67# Prototype Lab89A prototype answers one question. It is not production code with fewer tests.1011## Pick The Prototype Question1213Choose the branch:1415- Logic prototype: state model, workflow, parser, scoring, queue, rules, or business logic.16- UI prototype: layout direction, interaction model, variants, motion, or product feel.17- Integration prototype: unknown API/tool behavior, deployment constraint, or browser capability.1819If ambiguous, state the assumption and keep the artifact easy to delete.2021## Rules2223- Mark it as prototype/throwaway in path, UI, comments, or README.24- Use one command to run.25- Keep state in memory unless persistence is the thing being tested.26- Avoid broad abstractions, production plumbing, and hidden dependencies.27- Surface state after actions so learning is visible.28- Do not leave prototype code mixed with production code without a decision.2930## UI Variant Pattern3132When exploring design, create 2-4 meaningfully different variants. Let the user switch via route, query param, segmented control, or small debug toolbar. Do not make tiny color-only variations.3334## Logic Pattern3536When exploring state, make a terminal or local web harness that can run scripted cases and manual interactions. Print current state, event, output, and invariant violations.3738## Closeout3940When the prototype answers the question:4142- capture the decision in an issue, ADR, notes file, commit message, or final report;43- delete the prototype or identify exactly what will be absorbed into production;44- list what remains unproven.
markoblogo