用途：prototype 用于回答只有运行代码才能回答的设计未知，例如状态机形状是否成立、数据模型是否贴合、某个库是否可用、UI 手感是否合适。读代码、读文档或看 ADR 能回答的问题不应做原型。核心规则是：原型代码永不毕业（prototype code never graduates），交付物是决策，不是代码。
主要能力与做法：先写出原型必须回答的问题，用一句有可判定结果的话表述，例如“reducer 能否不用 history 数组表达 undo？”，而不是“探索 reducer”。没有问题就不做原型。设定时间盒，在声明问题时就设定（通常一到两小时，上限一天）；时间盒到期后，答案以现有证据为准，“未解决，原因是……”也是有效答案。只构建回答问题所需的最小实现，并明确声明跳过了什么，例如不写测试、不做错误处理、不润色命名，说明这是原型且问题关注状态形状；问题不涉及的部分全部硬编码。
提取与处置：记录答案，并提取承载决策的片段（状态机、reducer、schema 或类型形状），这些片段可比文字更精确地编码决策，可粘贴进 PRD。裁剪到决策相关部分，演示脚手架留在原地。最后删除分支或目录；生产版本按 tdd 测试优先重建，以提取出的决策作为规格。
与 tracer bullet 的区别：prototype 回答“应该是什么形状”，契约上是一次性的，故意没有质量；tracer bullet 回答“路径能否端到端跑通”，是保留并成长的生产质量垂直切片。若发现自己想保留原型，说明那本是 tracer bullet 问题，应停下并按该纪律重来。
输出契约：返回 question（构建它要回答的问题）、answer（决策，含否定或未解决结果）、snippets（供 PRD 使用的决策相关片段）、disposition（已丢弃，删除已执行而非承诺）。
限制与注意：不要让原型悄悄变成实现分支，一旦真实工作落在其上，就是在交付故意缺失质量的代码；不要原型化读代码或文档即可回答的问题，原型问题必须需要运行代码；负面结果也要记录，“这个库做不了 X”正是原型要换来的决策；不要润色，原型中花在命名、结构或边界情况上的时间都是从问题本身偷走的。