# Prototype

> Builds a clearly-marked throwaway prototype to answer a design question before committing to an implementation. Use when the user wants to sanity-check whether logic or a state model feels right, explore what a UI should look like, or asks to "prototype this", "試作して".

- Skill: `thinceller/prototype` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add thinceller/prototype`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinceller/prototype/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: thinceller (https://skillmd.com/u/thinceller)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinceller/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?"** → [references/logic.md](references/logic.md). Build a minimal interactive terminal harness that pushes the state model through cases that are hard to reason about on paper.
- **"What should this look like?"** → [references/ui.md](references/ui.md). Generate several radically different UI variants on a single route, switchable via a URL search param.

Getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, infer from 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 and named as such.** Locate the prototype near the module or page it's prototyping for, but name it so a casual reader sees it's a prototype, not production.
2. **One command to run.** Whatever the project's existing task runner supports — the user should never need to remember a path.
3. **No persistence by default.** State lives in memory. Persistence is what the prototype checks, not something it depends on.
4. **Skip the polish.** No tests, no error handling beyond what's needed to run, no abstractions.
5. **Surface the full state** after every action (logic) or on every variant switch (UI), so the user sees what changed.
6. **Capture and clean up when done.** Fold the validated decision into real code, then either delete the prototype or park it on a throwaway branch out of main — don't let it linger.