用途
Prototype 用于构建一次性原型来回答一个设计问题。核心原则是：原型的形态由它要回答的问题决定。问题不同，产出的工件也完全不同。
主要能力
该技能首先要识别正在回答哪个问题，依据用户的提示、周围代码，或如果用户在场就直接询问。它区分两条分支：
- “这套逻辑／状态模型感觉对吗？” → LOGIC.md：构建一个单一的可分享 HTML 文件，包含自由操作按钮和分标签的引导式走查，把状态机推进到难以用纸笔推理的场景，并且非开发者也能驱动。
- “这个应该长什么样？” → UI.md：在单个路由上生成多个差异显著的 UI 变体，通过 URL 搜索参数和底部悬浮栏切换。
两条分支产出的工件差异很大，因此判断错误会浪费整个原型。如果问题确实模棱两可且联系不上用户，则默认选择与周围代码更匹配的分支（后端模块 → 逻辑；页面或组件 → UI），并在原型顶部声明该假设。
两条分支共用的规则
- 从第一天起就是一次性代码，并清楚标记为一次性。把原型代码放在它真正会被使用的位置附近（紧挨着它所原型化的模块或页面），让上下文显而易见，但命名要让普通读者看出它是原型而非生产代码。对于一次性 UI 路由，遵守项目已有的路由约定；不要发明新的顶层结构。
- 运行要极其简单。UI 原型从项目任务运行器的一条命令启动：pnpm <name>、python <path>、bun <path> 等。逻辑演示则是用户双击即可打开的单个 HTML 文件。无论哪种方式，启动都不需要思考。
- 默认不做持久化。状态存在内存中。持久化是原型要检查的东西，而不是它应该依赖的东西。如果问题明确涉及数据库，就命中一个临时数据库或带有明确“PROTOTYPE, wipe me”名称的本地文件。
- 跳过打磨。没有测试，没有超出让原型可运行所需的错误处理，没有抽象。重点是快速学到东西。
- 展示状态。在每次操作（逻辑）之后或每次变体切换（UI）时，打印或渲染完整的相关状态，让用户看到变化了什么。
- 完成后捕获。把已验证的决策并入真实代码，然后把原型本身作为一手来源捕获：提交到一次性分支，脱离 main，并在实现 issue 上留下指向该分支的上下文指针。同时把答案（结论以及它解决的问题）记录在 issue 或提交中。main 分支只保留已验证的决策。
适用场景
当用户想要核实某个状态模型或逻辑是否合理，或探索某个界面应该采用什么外观时，适合使用本技能。它面向的是需要快速学习、而非交付生产代码的设计探索场景。
限制
资料未提供关于平台、收费、价格、具体效果等方面的信息。该技能本身规定原型不应包含测试、错误处理和抽象，默认不持久化，属于一次性工件。