用途：将需求方提供的 Word PRD（.docx）或粘贴的 PRD 文本，转换为结构化 Markdown，落到 docs/prd/<feature-name>/prd.md，供 grill-with-prd、原型类 skill、acceptance-checklist 等下游直接读取。只做转换与结构化，不发明需求，原文未写的标 [UNKNOWN]。
主要能力：按 8 个维度提取——业务背景、用户角色、功能模块、字段定义、业务流程、角色权限矩阵、校验规则、非功能与验收；表格优先作为精确信息源，流程图描述转为状态流转与操作序列，界面截图旁文字用于提取字段。证据标注沿用三分法：明确写了直接提取，能合理推出标 [INFERRED]，没提标 [UNKNOWN]，前后矛盾两处都记并列入待确认事项。
使用方式：.docx 需先自检环境——node --version 确认 Node.js ≥ 20，检查 scripts/node_modules 是否已装依赖，未装则执行 npm --prefix "<本 skill 目录>/scripts" install（mammoth、jszip、xml2js）。随后运行 node "<本 skill 目录>/scripts/extract-docx.mjs" "<docx 路径>" --output-dir ".claude/context/{源文件名}-extracted" --quiet，再用 Read 读 content.md。Node 不可用时给出各平台安装指引，并提供退路：直接粘贴 Word 内容，流程相同，但内嵌图片需自行截图。
feature-name 规则：纯英文 kebab-case，仅小写字母、数字、横杠，2~5 个词且总长 ≤ 40 字符，不含中文与 prd、v1、年份等修饰词；推导顺序为用户显式指定、文件名主语翻译、文档标题推导，多种合理译法时列 2~3 个候选让用户选。
保真度校验：走脚本时读 fidelity-report.txt，总分 ≥ 90 且无硬门槛告警可直接继续，70–89 或有 ⚠️ 需针对性补，< 70 或有 ❌ 需人工介入；硬门槛为图片文件提取率、图片引用率、表格提取率均需 ≥ 90%。粘贴文本路线跳过校验，但须在交付说明中注明未做保真度校验、未自动提取内嵌图片。
适用场景：手上是 .docx 文件或一大段粘贴的 PRD 文本。不适用：需求还停在口头、边界未清（用 requirement-clarify）；需求已清楚要直接写 PRD（用 prd-write 或 context-to-prd）；会议纪要、聊天记录（用 context-to-prd）。
限制：不做工程侧交叉验证（不扫数据库 DDL 或实体类）；中间产物 .claude/context/ 不作为交付物，最终 PRD 必须自包含，图片复制到功能目录并统一改写为 ./images/xxx；不省略保真度校验后仍声称提取完整。