这个 Skill 能做什么，适合哪些场景？
这个技能是 Xberg 仓库 54 个技能中的一个，路径为 .ai-rulez/skills/format-specific-extraction/SKILL.md。它本身不含可执行脚本，而是一套格式专属的提取工作流知识：Office XML、PDF、ZIP/TAR/7z/GZIP、JSON/YAML/TOML/XML 结构化文本、EML/MSG 邮件，各自应调用哪些验证器、解析器和源码模块。对维护或扩展 Xberg 提取器的开发者来说，它是精确的路线图；对只想调用提取 API 的普通用户来说，它更像内部工程文档。仓库整体以 MIT 协议开源，但本技能假定读者能读懂 Rust 代码引用（如 extractors/pdf/mod.rs）。
- Office XML（DOCX/PPTX/ODT）：先跑 ZipBombValidator，再解包 word/document.xml、ppt/slides/*.xml、content.xml，用 quick-xml 流式解析提取文本、表格与元数据
- PDF：经 pdf_oxide::PdfDocument::from_bytes 逐页提取文本，无可搜索文本或 force_ocr 时回退 OCR，可选提取表格
- 压缩包：任何解压前先做 ZipBombValidator 校验，列出文件元数据，仅提取纯文本文件，用 build_archive_result() 汇总
- 结构化文本：按 MIME 检测 JSON/YAML/TOML/XML，用对应库解析后美化输出
- 邮件：解析 EML/MSG 头部、提取正文（文本/HTML）、处理附件
- 新增格式：给出七步清单，从 MIME 注册、实现 DocumentExtractor trait 到特性门控与测试
- 正在为 Xberg 新增一种文档格式提取器的 Rust 开发者，需要知道实现 DocumentExtractor trait 的完整步骤和注册位置
- 审查提取管道安全性的工程师，想确认 Office 和压缩包路径上 ZipBombValidator、DepthValidator、StringGrowthValidator 的正确调用顺序
- 排查 PDF 提取结果的维护者，需要定位 pdf_oxide 的 OCR 回退条件和特性门控代码位置
- 为代理（Agent）配置文档提取知识的团队，希望模型按格式选择正确的工作流而不是瞎猜
- 只想装个库提取文档的终端用户——这是面向 Xberg 内部贡献者的工程参考，普通用户直接看 README 的安装与 Quick Start 即可
- 非 Rust 开发者——技能正文全部以 Rust 模块路径和 API 形式描述，没有 Python/Node 等绑定层面的等价说明
如何安装这个 Skill？
- 技能文档未包含明确的安全/权限指导，也未提及用户确认或数据流透明度。
- 某些功能（如基于提供商的OCR或LLM）可能依赖在中国可能无法访问的外部服务，应从中国网络环境评估可达性。
- 技能文档未定义明确的非适用范围或触发边界，可能导致误用。
- 技能本身没有版本控制或变更日志，维护责任不明确，更新路径未知。
- 本地文件系统
该技能随 xberg-io/xberg 仓库的 Agent Skills 插件分发，README 给出了以下安装方式：
Claude Code
/plugin marketplace add xberg-io/xberg
/plugin install xberg@xbergCodex CLI
/plugins add https://github.com/xberg-io/xberg安装后该技能位于仓库内 .ai-rulez/skills/format-specific-extraction/SKILL.md，属于 54 个技能之一。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 我要给 Xberg 加一个 .eml 之外的新邮件格式提取器，按 format-specific-extraction 的清单告诉我每一步改哪些文件
- 帮我检查一下压缩包提取路径：ZipBombValidator 应该在 build_archive_result() 之前还是之后调用？
- DOCX 里的表格被解析成单元格网格后，怎么转成 GitHub 风格的 Markdown 表格？
- 这个 PDF 没有可搜索文本，Xberg 会在哪一步触发 OCR 回退？
这是一份纯参考型技能，不含脚本和命令行操作。安装插件后，当任务涉及特定格式的提取实现、安全校验顺序或源码定位时，模型会读取 SKILL.md 中对应章节：Office XML 五步流程、PDF 的 pdf_oxide 流程、压缩包先校验后提取原则、结构化文本的 StructuredExtractor、邮件解析，以及新增格式的七步清单（EXT_TO_MIME 注册 → 实现 DocumentExtractor → 设置 supported_mime_types() 与 priority()（默认 50）→ register_default_extractors() 注册 → 特性门控 → 安全验证器 → 带 fixture 的测试）。
这个 Skill 有哪些优点和局限？
- 每条工作流都给出精确到文件的源码位置（如 extractors/docx.rs、extraction/office.rs），可直接定位代码
- 明确的安全顺序：压缩包必须在任何解压前跑 ZipBombValidator，Office 解析用 DepthValidator 和 StringGrowthValidator 防恶意输入
- 新增格式有完整的七步清单，含特性门控和测试要求，降低贡献门槛
- 纯知识文档，没有可执行脚本或自动化工具，所有操作仍需开发者手工完成
- 深度绑定 Xberg 代码库内部结构，脱离该仓库几乎不适用
- SKILL.md 未包含版本信息，无法确认与 Xberg 哪个版本的源码布局对应
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| Xberg 格式专属提取工作流指南 本页 | 66 · 推荐 | ★ 9.4k | 3 天前 | MIT |
| Xberg API 服务器与 MCP 协议集成 | 52 · 谨慎使用 | ★ 9.4k | 3 天前 | MIT |
| 文档纯文本提取器 ✓ Anthropic · 官方 | 52 · 谨慎使用 | ★ 422 | 1 个月前 | — |
| Skill Seekers 技能构建器 | 48 · 谨慎使用 | ★ 15k | 11 天前 | MIT |
| Azure 文档智能 Java 技能 ✓ Microsoft · 官方 | 46 · 谨慎使用 | ★ 2.7k | 3 个月前 | MIT |
Xberg 是 Kreuzberg（kreuzberg-dev/kreuzberg-v4-lts）的下一代重命名版本，同一引擎的 v1 新线；本文档描述的是 Xberg 侧的提取器实现工作流。
FollowSkills 如何评估这个 Skill？
该技能与Xberg文档提取框架紧密集成，明确承认对可能不可信的用户文档进行处理。仓库包含详细的安全策略、专门的输入验证器（ZipBombValidator、DepthValidator、StringGrowthValidator等）以及谨慎的默认安全限制，这些都对处理不可信输入进行了强有力的保障。但是，在技能层面缺少用户确认或数据流透明的显式机制；技能文档未涵盖权限、回滚或用户确认。该技能本身的功能范围是提取，不涉及外部网络调用，但OCR等某些功能可能依赖外部服务。因此，扣分是因为技能层面权限和确认指导不完整。
技能文档中的说明一致，格式特定的提取工作流清晰。仓库展示了广泛的测试和CI基础设施（例如，Docker CI、基准测试工作流、e2e测试）。但是，对于所选的技能路径，没有可用的测试或可复制的执行证据；技能文档仅引用源代码文件，没有提供测试或验证结果。指令自洽且结构合理，但缺乏测试方面覆盖和异常处理的证据。鉴于静态审查，最高分数被限制，这一项得分为9分，因为快乐路径看似可行，但错误处理和失败反馈的细节尚不清楚。
该技能针对明确的场景：从各种特定格式（Office、PDF、归档、结构化文本、电子邮件）中提取内容，这与真实需求高度契合。但是，非适配范围未明确定义；技能的名称和描述暗示一种通用提取技能，但仅涵盖格式特定的方面，未明确说明何时不应使用。此外，文档中提到复杂内容（如宏或受密码保护的文件）可能不支持，但未作为技能边界描述。就环境适宜性而言，没有提及中国相关服务或从中国网络的可达性；某些功能（如基于提供商的OCR或LLM）可能依赖中国可能无法访问的服务，但技能核心功能是本地处理。由于边界和触发条件证据不足，扣分。
技能文档组织良好，包含清晰的层级标题、图表和源代码引用，并遵循渐进式披露模式。许可证明确（MIT）。提供安装和依赖注意事项（表明Cargo功能标志）。维护责任（常规CI和版本控制）存在，但技能本身没有版本化或变更日志，也不清楚技能是否会定期更新。已知限制未明确记录在技能级别。由于缺乏版本控制和明确的维护责任，以及隐藏假设（例如，需要先构建项目），扣分。
公开的证据表明该技能能够完成核心任务，即提取指定格式的内容。仓库包含广泛的基准测试工作和针对各种格式的测试，表明其实际有效。然而，对于所选技能路径，缺乏直接可用的输出示例或验证结果。技能文档引用了实现细节，但没有展示关键路径的输出或提供代表性结果。收益与手动操作相比尚不明确。由于缺乏来自静态审查的直接可验证证据，最高分数限制为7分，且没有具体的可复制结果证明其有效性。
仓库包含大量可审计的主要材料：详细的CI工作流、基准测试配置、测试套件以及可复现的构建配置。这些材料为技能所基于的框架能力提供了支持性证据。然而，该技能的具体路径并未有单独的测试或验证，框架的覆盖范围分散。没有独立的验证或跨来源的证实。由于这是一次静态审查，且没有针对技能路径的专门测试，最高分数限制为5分，以获得部分证据。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →