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