prototypelisted

Build a throwaway prototype to flush out a question before committing to it. Routes between three branches — a runnable terminal app for state/business-logic questions (LOGIC), several radically different UI variations toggleable from one route (UI), or a focused spike that gives a binary verdict on whether a technical assumption holds (FEASIBILITY). Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, verify an `Uncertain` assumption from `/research` before `/write-a-prd`, or says "prototype this", "let me play with it", "try a few designs", "spike this", "can the library actually do X", or "is this feasible".
chrislacey89/skills · ★ 2 · AI & Automation · score 71

Install: claude install-skill chrislacey89/skills

# Prototype A prototype is **throwaway code that answers a question**. The question decides the shape. > **Forked from Matt Pocock's `/prototype` on 2026-05-11; kit-owned for iteration.** The LOGIC and UI branches are unchanged from upstream. The FEASIBILITY branch is a kit addition so `/research` and `/execute` can name a discharge route for `Uncertain` assumptions that are cheaply verifiable by code. ## Pick a branch Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around: - **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper. - **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar. - **"Does this approach actually work?"** → [FEASIBILITY.md](FEASIBILITY.md). Write a focused spike — one automated test or a temporary scratch route — that gives a binary verdict on whether a single technical assumption holds. Then delete the spike and fold the verdict into the calling skill's artifact. The three branches produce very different artifacts — getting this wrong wastes the whole prototype. The clearest signal: - If the question is about *which shape feels right* (state model, layout, API ergonomics), pick LOGIC or UI. - If the question is *yes