ln-prototype

# Ln Prototype A prototype is a disposable answer to one design question. Keep the verdict, not the artifact. Use `ln-prototype` when the question needs feel, play, or comparison. Use `ln-spike` when the question is technical feasibility or unknown API behavior. ## Input Prototype question or design uncertainty: $ARGUMENTS Orient first: 1. Read `memory/SPEC.md` if present; use its lexicon and live invariants. 2. Read `memory/PLAN.md` if present; identify whether the prototype serves an existing frontier item. 3. Read `HANDOFF.md` if present. 4. Inspect nearby code only enough to place the prototype where it is understandable and runnable. Write a 2-4 bullet orientation note: question, prototype branch, nearest seam/page/module, answer-capture path. ## Choose one branch Ask if ambiguous and the user is present; otherwise state the assumption. ### Logic prototype Use for state, transition, reducer, parser, planner, or workflow questions. Build a tiny interactive terminal app or CLI harness around a portable logic module. Good shapes: - pure reducer: `(state, action) => state` - explicit state machine with named states and legal transitions - small pure functions over plain data - state-owning module/class only when internal ongoing state is the question Keep the shell thin. The logic must not know about prompts, terminal escape codes, stdout, or UI widgets. ### UI prototype Use for layout, interaction, navigation, approval/recovery, inspection, or comparison questions. Generate several meaningfully different variants in one local route/page/screen, switchable by URL search param or floating switcher. Prefer adapting an existing page over inventing a playground. Variants should differ by design bet, not skin: name the bet each variant tests. ## Prototype discipline 1. **Throwaway from day one.** Name files/routes with `prototype`, `scratch`, or equivalent. Add: `PROTOTYPE — delete or absorb after verdict`. 2. **Near the real seam.** Keep context obvious; avoid public exports unless needed to run it. 3. **One command to run.** Use the repo's task runner and record the exact command. 4. **No persistence by default.** Use memory. If persistence is the question, use clearly wipeable scratch storage. 5. **No production polish.** Skip comprehensive tests, abstractions, analytics, and hardening beyond safe evaluation. 6. **Surface state.** After each logic action or UI variant switch, show relevant inputs, outputs, and state. 7. **One question only.** New questions become follow-up prototypes, spikes, or scope cards. ## Capture the verdict ```md ## Prototype Verdict: [question] **Branch:** logic | UI **Command:** [how to run] **What we tried:** [variants/actions/cases] **Verdict:** [decision or remaining uncertainty] **Absorb:** [what production code/spec/plan should inherit] **Delete:** [prototype files/routes/storage to remove] ``` Durability routing: - Requirements, assumptions, invariants, or lexicon changed → `ln-spec`. - Sequencing or frontier changed → `ln-plan`. - One implementation slice is now obvious → `ln-scope`. - Human judgment remains pending → record volatile state in `HANDOFF.md`. Do not create `CONTEXT.md`, ADRs, or alternate planning docs. Canonical docs are `memory/SPEC.md` and `memory/PLAN.md`. ## Cleanup Finish by stating one of: - deleted prototype files - kept prototype temporarily, with reason and deletion trigger - absorbed prototype into production through a scoped build If prototype files remain, they must be visibly non-production and easy to find. ## Routing After the verdict, present these options to the user (use `tool-ask-question`): | # | Label | Target | Why | | --- | -------------- | ------------ | --- | | 1 | Revise spec | `ln-spec` | Prototype changed durable understanding | | 2 | Revise plan | `ln-plan` | Prototype changed sequencing or frontier shape | | 3 | Scope a slice | `ln-scope` | Prototype answered enough to build | | 4 | Spike instead | `ln-spike` | The remaining question is technical feasibility | | 5 | Back to triage | `ln-consult` | Prototype did not settle direction | Recommended: **3** when the prototype produced a concrete build direction; **1** when it changed the model. --- *Adapted from [mattpocock/skills/engineering/prototype](https://github.com/mattpocock/skills/tree/main/skills/engineering/prototype).*