book-to-skill：把技术书"编译"成 Agent 能调用的知识库，15k Star
买了技术书读完就忘？PDF 堆在硬盘里 Agent 却用不上？book-to-skill 是一个把书籍/文档转换成 Agent Skill 的开源工具，让 AI 按需调用章节、术语与代码规则，而不是每次都把整本书塞进上下文。
先给你结论：book-to-skill 的价值不在"帮你少看 PDF"，而在把"读过的知识"从静态文件变成 Agent 能反复调用的工作能力。 它是个开源命令行工具，能把书籍、文档、论文目录转换成一整套分层的 Agent Skill——SKILL.md 管核心心智模型，chapters/ 管按需章节，glossary.md、patterns.md、cheatsheet.md 分门别类，让 AI 问到时按需加载，而不是每次把整本书塞进上下文。项目已在 GitHub 收获约 1.5 万 Star。
一句话结论
它解决三类浪费：PDF 在硬盘里但 Agent 不知道；笔记成了永不打开的长文；每次提问都让 Agent 重新翻目录、费 Token。 book-to-skill 的做法是"先付一次整理成本，把资料拆成结构化、可发现、可按需加载的知识资产"。
它生成什么
输入可以是一个文件、目录、glob 或多种格式混合；输出不是一篇总结，而是一套分层 Skill：
| 输出文件 | 作用 | Agent 何时读 |
|---|---|---|
SKILL.md | 核心心智模型、章节索引、使用入口 | 每次加载先读 |
chapters/ | 每章按需知识 | 问到具体章节 |
glossary.md | 术语与定义 | 遇陌生概念 |
patterns.md | 技术/算法/设计模式 | 解决类似问题 |
cheatsheet.md | 决策表、快速规则 | 快速查判断 |
关键不是文件多，而是把"核心知识"和"细节知识"分开，避免每次把整本书重新搬进对话。
四个值得关注的点
- 不是总结，是提炼"可执行知识"：普通摘要告诉你"这章讲了什么"；它按 practitioner voice 提炼成"什么场景该用、什么情况不该用、决策顺序、常见反模式"这种工作规则。
- 章节按需加载：运行时先读体积小的
SKILL.md，再按问题定位章节/术语表/patterns，省去反复发现和压缩的隐形成本。 - 技术书和文字书走不同提取路线：技术型用 Docling（保留 Markdown 表格/代码块），文字型用 pdftotext，按需回退。工程化地保留结构信息。
- 支持把新资料折叠进已有 Skill：能把新论文、章节、笔记合并进已有 Skill，让知识库持续演进，而不是每次从零生成孤立笔记。
三步看懂它
资料 / 目录 / glob
→ 选择提取路线(技术型 or 文字型)
→ 合并文本 + 元数据 + 来源标记
→ 分析标题/作者/章节/知识结构
→ 生成 SKILL.md、章节、术语表、patterns、cheatsheet
→ Agent 按需加载使用最简用法：
/book-to-skill ./my-book.pdf一次处理多份、或合并进已有 Skill：
/book-to-skill ~/papers/paper1.pdf ~/notes/export.txt unified-research
/book-to-skill ~/articles/new-paper.pdf ~/.claude/skills/project-knowledge它能怎么用
- 把《Designing Data-Intensive Applications》这类技术书编译成可查的架构 Skill
- 把团队架构文档、运行手册、onboarding 资料合成一套知识 Skill
- 把 RFC、API 合约、合规标准变成写代码时可查的规则库
- 把论文、实验记录和自己的笔记持续 fold in，形成研究 Skill
它真正适合的是"会反复用到、但不想每次重新翻"的知识。
边界与限制
它解决资料提取、结构化和按需加载，不是万能的：
- 生成质量依赖原始文档结构和提取器能力
- 扫描版、OCR 差、复杂排版可能仍需人工校验
- Skill 生成后仍需版本管理和更新策略
- "无幻觉"是目标，不能替代对关键结论的验证
- 生成的 Skill 能否被客户端发现，取决于是否支持对应 Skills 目录约定
小结
如果你正积累技术书、内部文档、论文或规范，建议先拿一份 20–50 页的资料试跑，看生成的 SKILL.md 有没有抓住核心心智模型，章节索引、术语表、patterns 和 cheatsheet 能不能真正辅助下一次工作。它最适合技术向、想把自己的知识库变成 Agent 工作能力的用户——这也是 AI 时代"知识资产化"一个很值得关注的方向。