用途：在功能实现前对 PRD 做逐项审查，通过一问一答的方式挑战需求的完整性、一致性和可实现性，直到对功能边界、实现路径和验收标准达成共识。
主要能力：挑战模糊需求，要求精确化；追问边界条件；发现并指出需求冲突；对照代码库验证描述是否一致；追问“范围外”是否遗漏；确认每条用户故事是否有明确验收标准。
使用方式：PRD 文件路径为 docs/prd/{feature-name}/prd.md，开始前先读取该文件；若用户未指定 feature-name 需先询问。每次只抛出一个问题，等用户回答后再继续，不一次性抛出全部问题。若某问题可通过探索代码库回答，先探索代码库而非抛给用户。决策被确认或修正时立即更新 PRD 文件，不攒到最后批量写，更新后告知用户修改了哪里。
自答模式：做演示或回归时可自己扮演回答方走完一轮，但回写 prd.md 时须标注结论为自答，不得伪装成用户确认；矛盾、冲突、缺失验收标准三类照常报出；需业务拍板的事项（范围取舍、优先级、价格、对外口径）即使自答也留在“待决问题”并写明归属人；交付时单独列出“自答”部分。
结束条件：所有主要分支追问完毕且 PRD 更新到位后，总结主要变更并告知可交付实现。
限制：资料未提供具体安装命令、收费、价格、平台或效果信息。