用途：在投入真实实现前，用一次性代码回答一个设计问题。问题决定原型形态：若用户能通过看屏幕回答，就是 UI 问题；若需要按按钮看状态变化，就是逻辑问题。
分支：逻辑问题（状态机/逻辑模型是否合理）走 LOGIC.md，构建小型交互应用，把状态机推过难以纸上推理的情况；UI 问题（应该长什么样）走 UI.md，在单一路由上生成多个差异悬殊的 UI 变体，通过 URL 搜索参数和底部浮动栏切换。两分支产物完全不同，选错会浪费整个原型；若问题真的含糊且联系不到用户，则按周边代码判断（后端模块→逻辑，页面或组件→UI），并在原型顶部声明该假设。
脚手架：写样板前先运行内置脚手架生成重复部分（切换组件、TUI 外壳、变体桩），再填写有趣部分。示例命令： npx tsx ${CLAUDE_PLUGIN_ROOT}/skills/prototype/scripts/scaffold.ts ui --variants 3 --framework next --outdir ./src/app/settings npx tsx ${CLAUDE_PLUGIN_ROOT}/skills/prototype/scripts/scaffold.ts tui --name checkout-flow --outdir ./src/checkout 脚手架支持 React UI（Next、React Router、Vite）和 TypeScript TUI；其他 UI 框架会生成 React 组件目录结构，需自行适配。
通用规则：从第一天起就是一次性代码并明确标记，放在实际使用位置附近，文件名或文件夹用 __prototype- 前缀或 prototype/ 子文件夹，避免与生产代码混淆；一次性 UI 路由遵循项目既有路由约定。一条命令即可运行（如 pnpm <name>、python <path>、bun <path>）。默认不持久化，状态存内存；如问题明确涉及数据库，用临时库或带“PROTOTYPE — wipe me”名称的本地文件。跳过打磨：除可运行所需外不做错误处理，不做抽象，不建测试套件（迭代中一个断言即可）。展示状态：每次操作后或每次切换变体时打印或渲染完整相关状态。完成即删除或吸收：原型回答完问题后，要么删除，要么把验证过的决定融入真实代码。
收尾：唯一值得保留的是答案。把它连同所回答的问题记录到持久位置（提交信息、ADR、issue 或原型旁的 NOTES.md）。用户在场则快速对话确认；不在场则留占位符，待其或下次补上结论后再删除原型。资料未提供具体收费、平台与效果信息。