用途：prototype 用于构建一次性（throwaway）原型来回答某个设计问题。问题的类型决定原型的形态，因此第一步是判断要回答哪个问题，可依据用户提示、周边代码，或在用户可联系时直接询问。
主要能力与分支： 1）逻辑/状态模型分支（LOGIC.md）：当问题是“这套逻辑或状态模型感觉对吗”时，构建一个可分享的单个 HTML 文件，包含自由操作按钮和分标签的引导式走查，把状态机推过那些在纸面上难以推理的情况，并让非开发者也能操作。 2）界面分支（UI.md）：当问题是“它应该长什么样”时，在单个路由上生成多个差异很大的 UI 变体，通过 URL 查询参数和底部浮动栏切换。 两个分支产物差异很大，判断错误会浪费整个原型。若问题确实含糊且联系不到用户，默认选择与周边代码更匹配的分支（后端模块→逻辑；页面或组件→界面），并在原型顶部说明该假设。
通用规则：
- 从第一天起就是一次性的，并明确标注。原型代码放在实际使用位置附近（被原型化的模块或页面旁边），但命名要让普通读者看出它是原型而非生产代码。一次性 UI 路由遵循项目既有路由约定，不要发明新的顶层结构。
- 运行要极其简单。UI 原型从项目任务运行器的一条命令启动，如 pnpm <name>、python <path>、bun <path> 等；逻辑演示是用户双击即可打开的单 HTML 文件。两种方式都无需思考即可启动。
- 默认不做持久化。状态保存在内存中。持久化正是原型要检验的东西，不应成为原型的依赖。若问题明确涉及数据库，则使用临时数据库或带有明确“PROTOTYPE, wipe me”名称的本地文件。
- 跳过打磨。不写测试，除让原型可运行外不做错误处理，不做抽象。重点是快速学到东西。
- 暴露状态。每次操作后（逻辑）或每次切换变体时（界面），打印或渲染完整的相关状态，让用户看到变化。
- 完成后归档。把已验证的决策并入真实代码，然后将原型本身作为一手资料保存：提交到 main 之外的一次性分支，并在实现 issue 上留下指向该分支的上下文指针。同时把答案（结论及其解决的问题）记录在 issue 或提交中。main 分支只保留已验证的决策。
适用场景：需要快速验证状态模型或逻辑是否合理、或探索界面应如何呈现时。
限制：资料未提供具体安装命令、依赖要求、支持平台、收费方式或效果保证；原型本身为一次性产物，不应作为生产代码依赖。