这个 Skill 能做什么，适合哪些场景？
doc-extract 是 healthcare 插件中的共享文档转文本技能，专门处理 PDF、DOCX、XLSX、PPTX、RTF 以及纯文本、Markdown 和 HTML 文件。它读取输入文件并将 JSON 输出到标准输出，不写入磁盘，也不创建缓存或临时文件。分页格式会保留页面标记，并报告实际使用的提取方法。安装依赖后适合需要把合同、EHR DocumentReference 附件或其他二进制文档交给后续流程处理的场景。
运行 scripts/extract.ts，按文件扩展名识别格式并读取输入文件；使用 liteparse 处理 PDF、DOCX、XLSX 和 PPTX（包含 OCR），使用 rtf-to-text 处理 RTF，使用 pdftotext -layout 作为部分 PDF 的回退方案，并直接透传纯文本、Markdown 或 HTML。命令向标准输出打印包含 text、method 和可选 pages 字段的 JSON；错误写入标准错误并以状态码 1 退出。分页文本之间会插入 === [page N] === 标记。
- 医疗系统集成者需要把下载的 EHR DocumentReference 附件转换为纯文本，以便后续处理。
- 合同处理流程需要先读取 PDF、DOCX 或 RTF 文档的文本内容。
- 数据工程师需要从 XLSX 或 PPTX 文件提取文本供脚本继续分析。
- 需要 OCR 的文档处理场景希望通过 liteparse 从 PDF、DOCX、XLSX 或 PPTX 中提取文字。
- 安全敏感的文档流程希望提取器不写入缓存、临时文件或其他磁盘状态。
如何安装这个 Skill？
- 文档声称依赖rtf-to-text并列出rtf-to-text方法，但package.json和代码实际使用自定义decoders.mjs；应同步文档、输出协议和依赖声明。
- 处理医疗文档时仍会启动第三方解析器并传递部分环境变量；部署方应审查代理、缓存、临时目录和资源限制，避免PHI外泄或资源耗尽。
- 表格列归属、OCR、加密文件、超大文件和异常格式未有测试证据；关键临床或计费结论必须回读原始文档并人工复核。
- 许可证、版本、变更记录和维护责任未在该技能材料中明确。
- Shell / 命令行
- 网络访问
- 本地文件系统
Bun@llamaindex/liteparsertf-to-textPoppler for the optional pdftotext fallback
先安装 healthcare 插件：/plugin marketplace add anthropics/healthcare，然后运行 /plugin install healthcare@healthcare。进入该技能目录 plugins/healthcare/skills/doc-extract/ 后执行 bun install。源材料未说明 Bun 的安装步骤或具体插件目录位置在不同客户端中的变化。
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/anthropics/healthcare.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/plugins/healthcare/skills/doc-extract" ~/.claude/skills/
rm -rf "$tmp"根据源仓库地址和 Skill 路径自动生成，只复制这个 Skill 的文件夹。如果上文有作者提供的安装方式，请优先按作者说明操作；想只在当前项目中使用，把 ~/.claude/skills 换成项目里的 .claude/skills。
如何使用这个 Skill？
在该技能目录中运行：bun scripts/extract.ts <input-file> [--content-type <mime>]。例如：bun scripts/extract.ts attachment.pdf，或对无扩展名的医疗附件运行 bun scripts/extract.ts attachment --content-type application/pdf。输出是包含提取文本和方法信息的 JSON；其他技能也可在 Bun TypeScript 中直接导入 extract 和 resolveLit。
这个 Skill 有哪些优点和局限？
- 覆盖 PDF、DOCX、XLSX、PPTX、RTF、纯文本、Markdown 和 HTML。
- 输出标准化 JSON，并报告实际提取方法和可用页数。
- 不写入磁盘，不使用缓存或临时文件，适合 PHI 敏感流程。
- 支持 PDF、DOCX、XLSX 和 PPTX 的 OCR 路径。
- 首次使用需要 Bun 以及从 npm 获取的 liteparse 和 rtf-to-text 依赖。
- 除 PDF 回退路径外，其他二进制格式依赖 liteparse；无扩展名文件不能走 liteparse。
- 多值列的表格可能发生列间交错，提取结果不能始终作为列归属的唯一依据。
- 源材料未提供测试套件、平台覆盖或性能数据。
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| 文档纯文本提取器 本页 ✓ Anthropic · 官方 | 52 · 谨慎使用 | ★ 425 | 2 个月前 | — |
| OfficeCLI 技能 | 38 · 不推荐 | ★ 32k | 13 天前 | Apache-2.0 |
| Azure 文档智能 Java 技能 ✓ Microsoft · 官方 | 46 · 谨慎使用 | ★ 2.7k | 3 个月前 | MIT |
| Azure 文档智能 .NET 技能 ✓ Microsoft · 官方 | 45 · 不推荐 | ★ 2.7k | 3 个月前 | MIT |
| Xberg API 服务器与 MCP 协议集成 | 52 · 谨慎使用 | ★ 9.4k | 12 天前 | MIT |
对于 PDF，工具会在适用时使用 pdftotext -layout 作为 liteparse 不可用时的回退方案；RTF 则使用 rtf-to-text。源材料未提供与其他完整产品的比较。
FollowSkills 如何评估这个 Skill？
代码显示采用只读文件处理、子进程环境变量白名单，并明确面向PHI且不写缓存；但仍传递HOME、临时目录及代理变量，依赖第三方解析器，未说明输入文件权限边界、资源限制或恢复策略，且缺少许可证信息，因此扣6分。
主路径、格式映射、PDF回退、错误JSON和退出码均有实现；但文档所述rtf-to-text依赖及method值与代码实际自定义RTF/XML解码不一致，未提供测试套件或异常输入覆盖，静态证据不足，因此扣13分并受静态上限限制。
明确面向多种医疗文档和EHR附件，支持扩展名及MIME类型，并说明表格和无扩展名文件的边界；但未说明中文/OCR质量、超大文件、加密文档及不适用场景，触发条件仍较概括，因此扣5分。
结构清晰，包含安装、命令、输出格式、表格限制和调用示例；但缺少版本策略、变更记录、维护责任、完整依赖锁定、许可证说明和故障排查，文档与实现存在过时信息，因此扣9分。
代码覆盖PDF、Office、RTF、XML及纯文本抽取，并输出页锚点和方法信息，核心任务可完成；但静态阅读无法验证解析正确性，表格列错位、OCR和格式完整性仍需人工复核，且输出可能需要后处理，因此扣9分并受静态上限限制。
源代码、类型配置和实现路径可审计，关键行为有注释；但没有提交测试、CI覆盖或第三方执行证据，文档依赖说明还与实现冲突，因此扣6分并受静态上限限制。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →