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