---
id: gh-prototype
name: "prototype"
url: https://skills.yangsir.net/skill/gh-prototype
author: mattpocock
domain: design
tags: ["prototype", "design", "ui-mockup", "state-machine", "rapid-development"]
install_count: 79300
rating: 4.70 (120 reviews)
github: https://github.com/mattpocock/skills/tree/main/skills/engineering/prototype
---

# prototype

> 构建一次性原型，在投入开发前验证设计。可用于状态/业务逻辑的终端应用，或多种UI变体切换。旨在快速探索设计、验证数据模型或UI，减少前期投入风险。

**Stats**: 79,300 installs · 4.7/5 (120 reviews)

## Before / After 对比

### 快速验证设计，降低返工风险

**Before**:

在没有原型的情况下，验证复杂的设计概念（如状态机或UI流程）需要耗费大量时间进行文档编写、会议讨论甚至部分实现，导致决策周期长且返工风险高。

**After**:

通过构建一次性原型，能够快速、直观地验证设计假设，及时发现潜在问题，显著缩短决策时间并大幅降低后续开发阶段的返工率。

| Metric | Before | After | Change |
|---|---|---|---|
| 概念验证时间 | 24小时 | 4小时 | -83% |

## Readme

# 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.

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 <name>`, `python <path>`, `bun <path>`, 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.


---
*Source: https://skills.yangsir.net/skill/gh-prototype*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-prototype/markdown*