用途
design-prototype 用于构建一次性（throwaway）原型来回答一个设计问题。问题的性质决定原型的形态。它适合在用户想要快速验证某个状态模型或逻辑是否合理，或探索界面应该呈现何种样貌时使用。
主要能力
该技能首先会识别正在回答的是哪一类问题，依据用户提示、周边代码，或在用户在场时直接询问，从而选择分支：
- “这个逻辑/状态模型感觉对吗？” → LOGIC.md。构建单个可分享的 HTML 文件（包含自由操作按钮以及分标签的引导式走查），推动状态机经过那些在纸面上难以推理、且非开发者也能操作的情况。
- “这应该长什么样？” → UI.md。在单一路由上生成多个差异明显的 UI 变体，可通过 URL 查询参数和底部浮动栏切换。
两个分支产出的工件差异很大，因此选错分支会浪费整个原型。如果问题确实模糊且无法联系到用户，则默认选择与周边代码更匹配的分支（后端模块 → 逻辑；页面或组件 → UI），并在原型顶部说明该假设。
使用方式
调用 /domain-modeling 来解析并读取项目已配置的工件；仅当本任务授权编辑时，才通过该所有者持久化已接受的模型变更。任何委派工作使用 /swarm，并采用实际的主机 schema、隔离的写入者和已披露的回退方案。
适用于两个分支的规则：
- 从第一天起就是一次性的，并明确标记为原型。将原型代码放在它实际会被使用的位置附近（紧邻它所原型化的模块或页面），使上下文显而易见，但命名要让普通读者能看出它是原型而非生产代码。对于一次性 UI 路由，遵守项目已有的路由约定，不要发明新的顶层结构。
- 运行极其简单。UI 原型从项目任务运行器的一条命令启动：pnpm <name>、python <path>、bun <path> 等。逻辑演示是用户双击即可打开的单个 HTML 文件。无论哪种方式，启动都无需思考。
- 默认不做持久化。状态保存在内存中。持久化正是原型要检验的东西，而不是它应该依赖的东西。如果问题明确涉及数据库，则使用临时数据库或带有明确“PROTOTYPE, wipe me”名称的本地文件。
- 跳过打磨。不写测试，不做超出原型可运行所需的错误处理，不做抽象。重点是快速学到东西。
- 展示状态。在每次操作（逻辑）后或每次变体切换（UI）时，打印或渲染完整的相关状态，让用户看到发生了什么变化。
- 完成后记录。记录问题、观察到的答案和剩余不确定性。通过 /domain-modeling 协调已接受的模型变更。将原型作为带标签的一手来源保存在项目选定的临时位置或授权的临时分支中，并从实现工件链接到它。仅当实现属于范围内时，才将决策并入生产代码；发布分支或 issue 评论遵循现有授权。主分支只保留已验证的决策。
适用场景
- 需要快速验证状态模型或业务逻辑是否合理。
- 需要探索某个页面或组件应该采用何种界面设计。
- 需要让非开发者也能操作并观察状态变化。
- 需要在正式实现前低成本地检验设计假设。
限制
- 原型是一次性代码，不应作为生产代码使用。
- 默认不做持久化，状态仅存于内存。
- 不包含测试、错误处理和抽象。
- 两个分支产出不同，选错分支会浪费整个原型。
- 关于具体收费、价格、平台支持等信息，资料中暂未提供。
完成标准
当所选分支产出可运行的工件、其相关状态可见，并且设计问题已获得观察到的答案或带有持久指针的明确不确定性时，任务完成。