用途：在正式承诺某套设计之前，用手动驱动的交互式终端应用（TUI）压测业务逻辑、状态转换或数据形态。当问题关于「状态机能否处理 X 后又 Y 的边界情况」「数据模型能否表达某场景」「API 表面应长什么样」时适用；若问题是「它该长什么样」，属于另一技能 /prototype:explore-directions。
流程要点：
- 明确写出要压测的状态模型与问题（文件顶部一段注释），避免回答错误问题。
- 选用宿主项目已有的语言与工具链，不为原型引入新运行时。
- 把核心逻辑隔离为可移植的纯模块，可选形态：纯 reducer（state, action）=> state、显式状态与转换的状态机、纯数据类型上的纯函数、或方法表面清晰的类/模块。保持纯净：无 I/O、无终端代码、不靠控制台输出控制流程，TUI 单向调用逻辑模块。
- 构建最小 TUI 暴露状态：每帧清屏后整体重绘，稳定单屏显示；分当前状态（逐字段美化输出，加粗字段名、弱化次要上下文）与底部动作列表（如 [a] 添加 [d] 删除 [t] 推进时钟 [q] 退出）；初始化单个内存对象、读取一次按键、派发处理、重绘替换而非追加，循环至退出。
- 用项目既有任务运行器封装一条命令（如 dotnet run --project <path> 或 pnpm run <name>），无任务运行器则把命令写到原型 README 顶部。
- 交付运行命令给用户，按需新增动作；对「这不该发生」「我以为 X 会不同」这类意外，视为想法本身的缺陷。
- 收尾时记录原型得出的结论；TUI 背后的逻辑模块常值得保留并提升到生产代码，TUI 外壳删除。
反模式：给原型加测试；接真实数据库（除非问题本身就是持久化）；过度泛化；逻辑与 TUI 混淆；把 TUI 外壳发布到生产。
限制：资料未提供具体安装命令、运行时依赖、平台支持或收费信息，暂未提供。