kscz0000 原型
何时使用
当此工作流与用户请求匹配时使用：构建临时代码原型以验证设计——用于状态/业务逻辑问题的可运行终端应用，或可在同一路由切换的多种截然不同的 UI 变体。
来源：mattpocock/skills（MIT 协议）。
原型是用于回答某个问题的临时代码。问题决定了原型的形态。
选择分支
识别正在回答的问题——来自用户的提示、周围代码，或在用户在场时直接询问：
- "这个逻辑/状态模型感觉对吗？" → LOGIC.md。构建一个小型交互式终端应用，将状态机推入那些在纸面上难以推理的边界情况。
- "这应该长什么样？" → UI.md。在单个路由上生成多种截然不同的 UI 变体，通过 URL 查询参数和浮动底栏切换。
两个分支产生截然不同的产物——选错分支会浪费整个原型。如果问题确实模糊且用户无法联系，默认选择与周围代码更匹配的分支（后端模块 → 逻辑；页面或组件 → UI），并在原型顶部声明此假设。
两个分支通用的规则
- 从一开始就是临时代码，并明确标注。 将原型代码放在实际使用位置附近（紧挨被原型的模块或页面），使上下文一目了然——但命名要能让随意浏览的人看出这是原型而非生产代码。对于临时 UI 路由，遵循项目已有的路由约定；不要发明新的顶层结构。
- 一条命令运行。 使用项目现有任务运行器支持的任何方式——
pnpm <name>、python <path>、bun <path>等。用户必须无需思考就能启动它。 - 默认不持久化。 状态存在于内存中。持久化是原型要_检验_的东西，而不是原型应该依赖的东西。如果问题明确涉及数据库，使用临时数据库或带有明显"PROTOTYPE — wipe me"命名的本地文件。
- 跳过打磨。 不写测试，不写超越让原型_可运行_的错误处理，不做抽象。目的是快速学到东西然后删除。
- 展示状态。 每次操作（逻辑）后或每次变体切换（UI）时，打印或渲染完整的相关状态，让用户看到变化。
- 完成后删除或吸收。 当原型回答了它的问题后，删除它或将验证过的决策融入真实代码——不要让它在仓库中腐烂。
完成时
_答案_是原型中唯一值得保留的东西。将它记录在某个持久的地方（提交消息、ADR、issue，或原型旁边的 NOTES.md），连同它所回答的问题。如果用户在场，这个记录就是一次简短对话；如果不在，留下占位符，以便他们（或你，下次经过时）在删除原型前填入结论。
限制
- 当工作流指定了上游工具、账户、API 密钥或本地设置时，需要相应的准备工作。
- 未经用户明确批准，不执行破坏性、生产环境、付费或外部消息操作。
- 在将生成的产物或建议视为最终结果之前，请对照用户的真实来源进行验证。