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. 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. 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. 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-or-no on a technical assumption (does the library expose this, does this configuration survive the streaming path, does this format render where we need it), pick FEASIBILITY.