virgiliojr94/book-to-skill

book-to-skill は、PDF・EPUB・Word などの文書を、エージェント用のスキルに変換するツール。要約を作るのではなく、その本が持っている考え方の枠組み、手法とつまずきの型、判断の基準を取り出して、あとから引ける形に組み替える。作ったスキルは Agent Skills という共通仕様に対応したホストから使える（Claude Code、GitHub Copilot CLI、Amp、Hermes Agent など）。

狙いは費用のかけどころを移すことにある。本をそのまま文脈に流し込むやり方だと、質問するたびに本1冊ぶんを読ませることになり、聞いた回数だけ費用がかかる。book-to-skill は構造化の手間を変換のときに1回だけ払い、以後は聞いた内容に見合った量で済むようにする。README は、ひとつの質問に答えるときに流れ込むトークンが、本を丸ごと文脈に入れる場合と比べて24〜51分の1になるとしている（実際の本で測った値）。

処理は2段。まず取り出す。形式ごとにパーサが分かれていて、PDF は取り出す前に「技術書か、文章中心か」を聞かれ、それに応じて道具が選ばれる（文章中心なら pdftotext、表やコードの多い技術書なら docling）。次に組み立てる。中心になる考え方と章の目次を書いた SKILL.md を作り、その下に章ごとのファイル、さらに用語集・パターン集・チートシートを並べる。章ファイルは聞かれるまで読み込まれないので、置いてあるだけでは容量を食わない。出力は既定で ~/.agents/skills/<slug>/ に置かれる（Hermes Agent のようにこの場所を見ないものは別の置き方になる）。取り出しと解析は手元で動き、元のファイルがこのツールから外へ送られることはない。ただし組み立てを担うのはエージェント側のモデルなので、クラウドのモデルを使っていれば、渡したテキストはその提供元の規約のもとに置かれる（README も同じ但し書きを付けている）。原文をそのまま写さず、言い換えた枠組みと定義として書き出す方針が明記されている。

社内のマニュアルや設計指針を、毎回貼り付けて渡しているとき

本以外にも使える。仕様書やデザイン指針のような毎回同じものを貼っている書類ほど、1回組み替えておく効果が出る。ただし中身を読んで組み立てるのはエージェント側のモデルなので、クラウドのモデルを使っている間は、渡したテキストは提供元の規約のもとに置かれる。README もそう但し書きするだけで、手元のモデルで組み立てる方法は示していない。外に出せない資料なら、使っているエージェントのモデル提供元の規約を先に確かめておきたい（記事の判断）。

分厚い技術書を、読み切る前に使いたいとき

章の目次と用語集が先にできるので、「今ぶつかっている箇所」から引ける（付属の説明によれば、章が自動で切り分けられるのは Chapter N や Capítulo N の形の見出しがあるときで、節見出しや章題だけの本は章を手で指すことになる）。通しで読む代わりに、必要になった章だけ開く形に変わる。

第三者の本から作ったスキルは配らない。 MIT ライセンスは変換する側のコードにかかるもので、処理した本には及ばない。README も、生成物は個人の学習ノートとして扱い、第三者の著作物から作ったスキルを再配布しないよう促している。社内文書や自分で書いたものが元なら、そのライセンスの範囲で共有して構わない、とも書かれている。

紙をスキャンした PDF はそのままでは通らない。 文字情報が無いため、先に OCR をかける必要がある。

書き出しの質は、元の本の性格に左右されそうだ（記事の見立て）。 取り出しているのが枠組み・パターン・判断の基準なので、手順や原則がはっきりしている実務書とは噛み合いやすい一方、筋や描写そのものが中身である本では、抜き出せる形が少なくなることが考えられる。

追加の導入が要ることがある。 表やコードの多い PDF を通す docling などは別に入れる。足りない場合は、必要なインストール手順が表示される作りになっている。