create-prd 用于创建产品需求文档（PRD）：把原始想法、工单或痛点转化为团队可以据此设计和构建的产品规格。它回答的是“要构建什么、为什么构建”，即用户体验、功能与行为；技术实现则留给下游的 TDD。
使用方式
该技能仅当用户明确按名称调用时才使用。它以引导式对话运行：先确认基础，即问题是什么、成功是什么样子，然后一次一个问题地梳理解决方案，并在每次回答后重新改写文档，使其始终读起来像一份连贯的规格，而不是问答记录。
对话规则
每条消息只提一个问题，消息末尾只出现一个问句，不接受堆叠追问或“另外还有……”。给出 2-3 个选项让用户选择仍算一个问题；把多个独立决策塞进同一条消息则不允许。按决策树逐个推进：给出决策、选项、权衡与推荐，然后停下等待。若有多处未定，只问那个能解锁其余问题的问题。不要问笼统的“有什么反馈？”。
每个决策都按访谈循环进行；只在决策真正确定后才更新文档。用户未必直接作答，可能反驳、边想边说或反过来提澄清问题，这仍属于讨论的一部分，不是决策，应回答并继续讨论，不要改动文档。单条用户消息本身不是改文档的信号，讨论中途改稿会破坏规格。决策确定后才写入文档并进入下一个问题。
写入已确定的决策时，应重写相关章节而不是追加内容：合并决策，改写文字、重绘原型或图、调整或删除原有内容。单个决策常会波及已初步成形的部分。用最能表达决策的形式记录，例如原型、图或草图。
文档始终是对已知内容的连贯描述，绝不是日志。任何时候 PRD 都应像有人特意撰写的规格：高层、连贯、当前，而不是答案清单或决策变更记录。每得到回答都把它当作重新描绘的理由，重构、重排、重建该章节。整段重写是常态而非例外。
展示而非讲述。讨论任何视觉内容（界面流程、布局、交互、状态）时，创建 HTML 原型并内联显示。草图比大段文字更能传达信息。决策演进时保持原型同步更新。
让它读起来像人写给人的文档。读者只看标题就应能了解产品轮廓。每个章节和小点都要有说明结论的标题，像好幻灯片标题那样陈述信息（“评审者无需登录即可评论”），而不是泛泛的主题标签（“分享”）。段落保持简短，原型或图紧挨其说明文字放置，不要把文字堆成墙、把视觉素材全堆在末尾。先给结论，再给支撑。
停留在产品层面。只问产品问题：用户体验、功能和行为。若涉及数据库结构、存储位置或实现架构，记入“Deferred to TDD”章节后继续。
需要更多上下文时获取。当决策取决于产品或代码库的实际运作方式时，在给出选项前启动 Agent() 调用（codebase-locator、codebase-analyzer、codebase-pattern-finder、web-search-researcher 或库研究者），并把新发现合并回研究产物。
不要求上游产物。产品背景可能是一份详细工单、研究文档，或仅几句描述用户想要什么的话；从现有内容出发。用已有输入支撑 PRD 并在撰写时引用，如“根据工单……”“研究文档指出……”。不要把上游内容复制进 PRD，应引用。若上下文稀薄，不要凭空发明需求，把缺口作为问题在访谈中提出，由用户补充。
原型设计系统
若涉及 UI/UX，原型应匹配用户产品自身的颜色、字体、间距和组件，而非本应用。先查研究文档中的设计系统细节；若未记录，在构建原型前启动 codebase-analyzer 询问：$PRODUCT_AREA 使用什么设计系统或组件库？主色（含十六进制）、字体、间距、边框、阴影？存在什么主题系统（如有）？
初始骨架
骨架尽量精简，无前言、无铺垫、无总结。越快到达第一个问题，用户越能保持投入。只写：含 type: design-prd 的前置信息和顶层标题；一个“Problem to Solve”章节与初稿问题陈述；空的“成功是什么样子、如何衡量”“拟议解决方案”“解决方案细节”标题，通过访谈逐步填充。然后立即以第一个问题开启基础部分：最多一句简短引导，然后提问。引用你起草的实际“Problem to Solve”内容，让用户针对确切措辞而非摘要回应。
嵌套代码块：当 markdown 中要展示含代码块（内含反引号围栏）的 markdown 时，外层使用 4 个反引号，避免内层 3 反引号提前闭合。
a. 要解决的问题：用户对首个问题中引用的陈述作出反应，反复迭代 until 满意，然后重写该章节反映商定措辞。
b. 成功的样子：问题确定后转向成功。目标是就如何知道功能确实为用户带来结果达成一致，作为发布后可读取的杠杆，并纳入完成定义。保持灵活并贴合工作内容，不限于产品分析：该技能服务后端内部工具、全栈产品、DevOps 等，杠杆可能是产品指标、采用信号、基准、错误率或延迟目标，或定性判断。值得做的事就值得衡量。提出指标或几个选项并附推荐，若相关可引用实验或功能开关，迭代至用户满意。很小的改动可能没有合理杠杆；若如此，如实说明并在用户同意后记录，而非编造指标。然后重写相应章节。只有问题和成功指标都确定后才开启解决方案访谈（第 4 步）。
解决方案访谈：对每个决策，提出单个决策及选项和推荐（UI 问题用原型展示“选项 A 与选项 B”并各附内联原型），反复沟通至决策确定（澄清与反驳属于过程，不是改稿信号），然后重写“解决方案细节”吸收该决策，保持为一份连贯规格。能用原型或图表达时就用。当回答重塑工作时，同一次修改所有受影响章节：细化“拟议解决方案”（如高层方法变化）、把被排除路径移入“范围外”、保持原型与文字同步。若用户要求修改原型，暂停提问流程，迭代原型至批准后恢复。原型获批后用 task-artifact 块嵌入文档（若尚未嵌入）。
停留在产品层面，只问产品问题；若问题实际涉及 schema、存储或实现架构，记入“Deferred to TDD”继续。
原型是视觉沟通方式，讨论 UI 时多用。把 HTML 文件写入 .humanlayer/tasks/{task-slug}/mockup-{description}.html，遵循第 1 步找到的用户产品设计系统（颜色、字体、组件），使用真实标签而非占位文本，每个原型聚焦当前决策，并内联显示该路径。决策演进时更新原型，最终 PRD 嵌入“胜出”版本。
收尾：向用户确认解决方案是否完整，请其从头到尾阅读“解决方案细节”并确认连贯，等待批准并纳入修正。