用途：把「一句话需求」采访成可以写 PRD 的输入。需求不完整时 AI 不会停下来问，而会按自己的理解补全，因此缺口必须在落笔前问出来。
适用与不适用：适用于需求还停留在口头、聊天记录或一句话描述，需求来源方只讲清「要什么」没讲边界。不适用于需求已完全明确（用 prd-write）或已有充分上下文（用 context-to-prd）。与 grill-with-prd 的区别：本 Skill 在 PRD 成文之前做建设式采访，产出 clarify.md；grill-with-prd 在成文之后做对抗式压测，直接写回 prd.md，两者不可互相替代。
开始前：确定短横线格式的功能名 <feature-name>，目标目录 docs/prd/<feature-name>/。先查代码库、已有 PRD、docs/product/ 下的体验基线，能查到的不问用户；把用户已说过的内容整理成「已知」清单，采访从已知之外开始。
采访规则：一次只问一个问题，等回答后再问下一个；每个问题给出推测的默认答案让用户确认或纠正；用户答不上来记为 [UNKNOWN] 并标注需要谁决定，不替他编。
要问清五类信息：目标角色（谁用、几个角色、权限差别）、触发场景（何时用、从哪进入）、范围（这一期做什么、做到什么程度）、明确不做（看似相关但本期不做，用户常漏，必须主动追问）、已知约束（时间、合规、依赖的上下游系统）。
产物：写入 docs/prd/<feature-name>/clarify.md，包含已知事实（来源可追溯）、目标角色与权限差异、触发场景与入口、范围/明确不做、已知约束、待决问题。沿用仓库证据标注约定：事实标来源，合理推断标 [INFERRED]，无法确认标 [UNKNOWN] 并写明归属人。
结束条件：五类信息每类都有明确答案，或已作为 [UNKNOWN] 记录并指明归属人。不追求问完，把「还不知道」显式留下比当场编答案更有价值。
自答模式：无人回答时可自行给出默认答案，结论标 [自答]，不写成用户说过的话。两条底线：涉及业务决策（价格、权益、优先级、上线范围）即使自答也落成 [UNKNOWN] 并写明归属人；能从代码库或已有 PRD 查到的仍先查。交付时把用户确认的、自答的、仍为 [UNKNOWN] 的三类分开讲清楚。
不做什么：不写 PRD 正文；不替用户拍板业务决策；不一次性抛出所有问题；不重复问代码库里查得到的事。
下一步：把 clarify.md 交给 prd-write 写新 PRD，上下文足够充分时也可直接进 context-to-prd 成文。