# Prototype > Build a throwaway prototype to flush out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use ONLY for two scenarios — (1) the user needs to compare multiple structurally different UI approaches side by side before picking one, or (2) the user needs to manually step through a state machine / data model that is hard to reason about on paper. For building a real page or polished UI, use ui-ux-pro-max / hallmark instead — this skill produces throwaway code. - Skill: `davie521/prototype` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add davie521/prototype` - Raw SKILL.md: https://api.skillmd.com/api/skills/davie521/prototype/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: Davie521 (https://skillmd.com/u/davie521) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/davie521/prototype --- # Prototype A prototype is **throwaway code that answers a question**. The question decides the shape. ## 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. Neither branch builds a real page: if the user wants one polished production UI rather than several throwaway comparisons, hand off to `ui-ux-pro-max` or `hallmark` instead. The two branches produce very different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype. ## Rules that apply to both 1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure. 2. **One command to run.** Whatever the project's existing task runner supports — `pnpm `, `python `, `bun `, etc. The user must be able to start it without thinking. 3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is *checking*, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name. 4. **Skip the polish.** No tests, no error handling beyond what makes the prototype *runnable*, no abstractions. The point is to learn something fast and then delete it. 5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed. 6. **Delete or absorb when done.** When the prototype has answered its question, either delete it or fold the validated decision into the real code — don't leave it rotting in the repo. ## When done The *answer* is the only thing worth keeping from a prototype. Capture it somewhere durable (commit message, ADR, issue, or a `NOTES.md` next to the prototype) along with the question it was answering. If the user is around, that capture is a quick conversation; if not, leave the placeholder so they (or you, on the next pass) can fill in the verdict before deleting the prototype. ## Use with - `to-prd` — when a logic prototype produces a state-machine or schema snippet that encodes a decision more precisely than prose, inline that snippet in the PRD's Implementation Decisions (the to-prd template explicitly allows this exception for prototype outputs). - `grill-with-docs` — when the user is ambivalent between options, run a grill session first to surface what question the prototype should answer. A prototype that answers the wrong question is pure waste. - `improve-codebase-architecture` — when a logic prototype validates a new module shape, this skill is the right next step to plan how to fold it back into the real codebase as a deep module. ## Origin Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) — `engineering/prototype`. License: MIT.