llm-wiki — 個人知識ベース構築システム

断片化された情報を、継続的に蓄積され、相互にリンクされた知識ベースに変換します。素材を提供するだけで、AI がすべての整理作業を行います。

このスキルは何をするか

llm-wiki は継続的に成長する個人知識ベースの構築をサポートします。従来のノートソフトではなく、AI があなたの代わりに保守する wiki システムです：

• 素材（リンク、ファイル、テキスト）を提供すると、AI がコア知識を抽出し、相互にリンクされた wiki ページに整理します
• 知識ベースは使用するたびにより豊かになり、毎回最初からやり直すことはありません
• すべてのコンテンツはローカル Markdown ファイルです。Obsidian や任意のエディタで閲覧できます

中核理念

従来の方法（RAG/チャット履歴）の問題点：質問するたびに、AI は元のファイルをはじめから読み直す必要があり、蓄積がありません。知識ベースの価値は知識が一度コンパイルされ、その後継続的に保守されることにあり、毎回再導出されることではありません。

クイックスタート

ユーザーに説明するのはこの 2 ステップだけで十分です：

1. 初期化：「知識ベースを初期化してください」と言う
2. 素材を追加：リンクやファイルを提供して、「これを消化してください」と言う

---

スクリプトディレクトリ

スクリプトは scripts/ サブディレクトリに配置されています。

パス解決：

1. SKILL_DIR = このSKILL.mdのディレクトリ
2. スクリプトパス = ${SKILL_DIR}/scripts/<script-name>

---

依存関係チェック

コア主線（ローカルファイル、純テキスト、既存知識ベース操作）はデフォルトではこれらの抽出依存は不要です。

ユーザーが URL 類の素材源を提供し、ウェブページ / X / WeChat公開アカウント / YouTube / Zhihu コンテンツの自動抽出を明確に要求する場合にのみ、以下のオプション依存をチェックしてください。

不足している場合は、ユーザーに以下を実行するよう指示してください：

bash ${SKILL_DIR}/install.sh --platform <現在のプラットフォーム> --with-optional-adapters

オプション依存スキル / ツール：

• baoyu-url-to-markdown — 一般的なウェブページ、X/Twitter、一部 Zhihu 抽出
• wechat-article-to-markdown — WeChat公開アカウント抽出
• youtube-transcript — YouTube字幕抽出

これらの依存が不足していても、スキルは機能します（ユーザーはローカルファイルを直接提供したり、テキストを貼り付けたり、または手動エントリを使用できます）。

アダプタステータスモデル

アダプタの失敗は not_installed / env_unavailable / runtime_failed / unsupported / empty_result の 5 つのカテゴリに統一分類されます。

素材源を列挙したり、source_label、raw_dir、adapter_name、fallback_hint を読む必要があるすべての場所で、まず素材源レジストリを読んでください：

bash ${SKILL_DIR}/scripts/source-registry.sh list

単一の素材源の定義が必要な場合は、以下を使用してください：

bash ${SKILL_DIR}/scripts/source-registry.sh get <source_id>

URL 類素材源について、まず以下を実行してください：

bash ${SKILL_DIR}/scripts/adapter-state.sh check <source_id>

adapter-state.sh check は 8 列を返します：

source_id	source_label	state	state_label	detail	recovery_action	install_hint	fallback_hint

• not_installed：ユーザーに補完インストール可能であることを提示し、同時に手動エントリへの切り替えを許可します
• env_unavailable：不足している環境条件を説明し、同時に手動エントリへの切り替えを許可します
• runtime_failed：このエクストラクション実行の失敗を説明し、1 回の再試行を許可し、その後手動エントリに切り替えます
• unsupported：手動エントリを直接提示し、自動エクストラクションを試みません
• empty_result：自動エクストラクションが有効なコンテンツを取得できないことを説明し、ユーザーにテキストを手動で補完するよう依頼します

自動エクストラクションの実際の実行後、以下を再度実行してください：

bash ${SKILL_DIR}/scripts/adapter-state.sh classify-run <source_id> <exit_code> <output_path>

返された detail、recovery_action、install_hint、fallback_hint を使用してプロンプトを生成してください。コア主線はアダプタ失敗で中断されません。

---

ワークフロールーティング

ユーザーの意図に従って、対応するワークフローにルーティングします：

ユーザー意図キーワード	ワークフロー
「知識ベースを初期化」、「新しい wiki を作成」、「知識ベースを作成」	→ init
URL / ファイルパス / 「素材を追加」、「消化」、「整理」 / 直接リンク提供	→ ingest
「一括消化」、「これらをすべて整理」 / フォルダパス提供	→ batch-ingest
「XX について」、「クエリ」、「XX は何か」、「まとめて」	→ query
「XX について教えて」、「XX を深く分析」、「XX の概観」、「XX をダイジェスト」	→ digest
「X と Y を比較」、「X と Y の違い」、「時間軸を整理」、「時系列で並べる」	→ digest（形式指定）
「知識ベースをチェック」、「健康チェック」、「lint」	→ lint
「知識ベース状態」、「今何があるか」、「素材はいくつあるか」	→ status
「知識グラフを描画」、「関連図を見る」、「グラフ」、「知識ベースマップ」	→ graph
「素材を削除」、「削除」、「ソースを削除」、「移除」	→ delete
「結晶化」、「結晶化」、「これを知識ベースに記録」、「このチャットを要約」	→ crystallize

重要：ユーザーが直接 URL やファイルを提供しても、何をするか明確に指定しない場合は、デフォルトで ingest ワークフローを使用します。知識ベースがまだ存在しない場合は、init を自動的に実行してから ingest を実行します。

---

通用前置チェック

init を除く他のワークフローは、デフォルトで最初にこのチェックを実行します：

1. 現在の作業ディレクトリに .wiki-schema.md が含まれているかを最初にチェックしてください
   • 含まれている → 現在のディレクトリを知識ベースルートパスとして使用します
   • 含まれていない → ~/.llm-wiki-path の読み取りにフォールバックします
2. 両方共に存在しない場合：
   • ingest / batch-ingest → 最初に init を実行します
   • query / lint / status / digest / graph / delete → ユーザーに知識ベースを最初に初期化するよう通知します
3. 知識ベースルートディレクトリ下の .wiki-schema.md を読み取ります
4. .wiki-schema.md の「言語」フィールドから WIKI_LANG を判定してください
   • 言語：中文 → WIKI_LANG=zh
   • 言語：English → WIKI_LANG=en
   • フィールド欠落 → デフォルト WIKI_LANG=zh

出力言語規則

すべてのユーザー向け出力と新しく書き込まれた wiki コンテンツは、WIKI_LANG に従って生成されます：

• WIKI_LANG=zh → 以下の中国語の例を使用します
• WIKI_LANG=en → 中国語の例と同じ構造、情報量、順序を保ちながら、自然な英語の表現に変更します
• ファイルパス、wiki リンク、ディレクトリ名は現在の規約を保ち、言語切り替えで変更しません

用語対照表：

• 素材 → Source
• 実体 → Entity
• 主題 → Topic
• 摘要 → Summary
• 総合 → Synthesis
• 消化 → Ingest
• 対比 → Comparison
• 深度報告 → Deep Dive Report
• 知識グラフ → Knowledge Graph

---

ワークフロー 1：init（知識ベース初期化）

前置チェック（複数知識ベース CWD チェック含む）

1. 現在の作業ディレクトリに .wiki-schema.md が含まれているかを最初にチェックしてください
   • 含まれている → 現在のディレクトリはすでに知識ベースです。ユーザーに存在を通知し、再初期化するかどうかを確認してください
2. 現在のディレクトリに無い場合 → ~/.llm-wiki-path ファイルを読み取ります
   • 存在する場合 → ユーザーに既存の知識ベース（パス表示）があることを通知し、新規作成するか既存に切り替えるかを質問します
3. 両方共に無い → 初期化フローに入ります

ステップ

1. 知識ベースのテーマを質問（ユーザーに最初に質問する）：

   • 「知識ベースのテーマは何ですか？例えば『AI学習ノート』『製品競合分析』『読書ノート』」
   • ユーザーが考えなければ、デフォルトで「マイ知識ベース」を使用します

2. 知識ベースの言語を質問（ユーザーに最初に質問する）：

   • 「知識ベースコンテンツはどの言語で使いますか？中文 / English（デフォルト中文）」
   • 選択肢：zh（中文）または en（English）
   • ユーザーが明確に指定しない場合、デフォルト zh
   • 選択を WIKI_LANG（zh または en）として記録します

3. 保存位置を質問（ユーザーに最初に質問する）：

   • デフォルト：~/Documents/マイ知識ベース/（zh）または ~/Documents/my-wiki/（en）
   • ユーザーはパスをカスタマイズできます

4. 初期化スクリプトを実行：

   bash ${SKILL_DIR}/scripts/init-wiki.sh "<パス>" "<テーマ>"
   

5. 初期化結果の説明を追加：

   • init-wiki.sh は同時に purpose.md と .wiki-cache.json を生成します
   • purpose.md と .wiki-schema.md は同じレベルに配置され、研究目標、主要な質問、研究範囲を記録するために使用されます
   • ユーザーに中核目標と主要な質問を優先的に記入するよう促してください。これらの内容は purpose.md に書かれ、後続の ingest はここの方向性を優先的に参照します

6. 言語設定を書き込み、シードファイルをローカライズ：

   • .wiki-schema.md の 言語：{{LANGUAGE}} を以下で置き換えます：
     • zh → 言語：中文（シードファイルは中国語のまま、追加処理不要）
     • en → 言語：English、同時に以下のシードファイルを英語版で上書きします：
   • WIKI_LANG=en の場合、${SKILL_DIR}/templates/index-en-template.md、${SKILL_DIR}/templates/overview-en-template.md、${SKILL_DIR}/templates/log-en-template.md を読み込み、{{DATE}} と {{TOPIC}} を実際の値に置き換えた後、それぞれ index.md、wiki/overview.md、log.md に書き込みます

7. パスを ~/.llm-wiki-path に記録：

   echo "<パス>" > ~/.llm-wiki-path
   

8. ガイダンス出力（WIKI_LANG に従って言語を切り替える）：

   中国語（zh）：

   知識ベースが作成されました！パス：<パス>
   
   次のことができます：
   - リンクを提供すれば、自動的に抽出して整理します（ウェブページ、X/Twitter、公開アカウント、Zhihu など）
   - 小紅書コンテンツはテキストを直接貼り付けてください（自動抽出はまだサポートしていません）
   - ローカルファイルパスを提供してください（PDF、Markdown など）
   - テキストコンテンツを直接貼り付けてください
   - 一括消化：フォルダパスを提供してください
   
   推奨：Obsidian でこのフォルダを開き、知識ベースの構築効果をリアルタイムで確認してください。
   

   （英語版は「出力言語規則」に従って生成し、構造は同じです。）

---

ワークフロー 2：ingest（素材を消化）

これが最もコアなワークフローです。ユーザーが素材を提供すると、AI がすべての整理作業を行います。

前置チェック

通用前置チェックを実行してください（上記の定義を参照）。

プライバシー自己チェック提示（ingest に初めて入る際は必須実行）

コンテンツを抽出または分析する前に、AI はまずユーザーに次の文を言い、確認を待つ必要があります：

この素材の分析を始める前に、以下の敏感なコンテンツが含まれていないことを素早く確認してください：

• 電話番号（例：138xxxxxxxx）
• 身分証明書番号（18 桁の数字）
• API キー（sk-...、AIzaSy...、OPENAI_API_KEY=、ANTHROPIC_API_KEY=、Bearer ...）
• 平文パスワード（password=、passwd=）
• 知識ベースに入れたくない他の個人情報

素材に上記の項目が含まれている場合は、テキストエディタで削除またはマスキング後に続行してください。 llm-wiki は自動的にこれらのコンテンツをフィルタリングしません。処理済みコンテンツは知識ベースに入ります。

上記のコンテンツがないことを確認したら、y で返信してください。中止する場合は n で返信してください。

フロープロセスルール：

• ユーザーが y（または「大丈夫」、「続ける」、「ない」などの明確な肯定）で返信 → 後続ステップを続行します
• ユーザーが n（または「停止」、「キャンセル」などの明確な否定）で返信 → このingest を終了し、ユーザーにクリーンアップ後に再度来るよう通知します
• その他の不明確な返信 → もう一度聞きます。最大 2 回まで。2 回とも明確な y/n でない場合は終了します
• バイパスルール：現在のチャットでユーザーが既に「素材に敏感情報がなく、直接開始する」と明確に言っている場合、 または batch-ingest フロー内にある場合（既にトップレベルで一度確認済み）、この手順をスキップできます

自己チェックリスト而不是脚本の理由：

• 正規表現は非構造化テキスト（チャット履歴、ノート）で誤検出率が高く、真の敏感な単語を見落とし、無害な一般的な単語を誤検出します
• 判断権をユーザーに返す方が、スクリプトに判断させるより信頼性が高いです
• 初心者フレンドリーで、わかりにくいスクリプトエラーに遭遇しません

素材エクストラクションルーティング

素材タイプに基づいて自動的に最適なエクストラクション方法にルーティングします：

アダプタ前置判定：

• URL には bash ${SKILL_DIR}/scripts/source-registry.sh match-url "<url>" を呼び出してください
• ローカルファイルには bash ${SKILL_DIR}/scripts/source-registry.sh match-file "<path>" を呼び出してください
• 純テキスト貼り付けには bash ${SKILL_DIR}/scripts/source-registry.sh get plain_text を直接呼び出してください
• source-registry.sh は 10 列を返します：source_id、source_label、source_category、input_mode、match_rule、raw_dir、adapter_name、dependency_name、dependency_type、fallback_hint
• bash ${SKILL_DIR}/scripts/adapter-state.sh check <source_id> を呼び出してください
• adapter-state.sh check の 8 列結果から state、detail、recovery_action、install_hint、fallback_hint を読んでください
• state=not_installed / env_unavailable / unsupported の場合 → アダプタを呼び出さず、detail、recovery_action、install_hint、fallback_hint に従ってユーザーに次のステップを説明します
• available が返された場合にのみ、自動エクストラクションを続行します

URL 類素材（素材源レジストリを統一的に使用し、ドメイン表を手書きしない）：

Chrome 提示（adapter_name=baoyu-url-to-markdown の場合のみ）： adapter-state.sh check は「エクストラクタが利用可能」と「9222 再利用可能セッションが存在するか」を分けて表現します。 check が available を返す場合、通常アダプタを呼び出してください。detail が 9222 未検出を示唆していても、実行を続けてください。baoyu-url-to-markdown は自分で Chrome 起動を処理します。実行を続行し、ユーザー確認を待たないでください。 既に ログイン状態の Chrome セッションを複製したい場合にのみ、手動で 9222 を有効化する必要があります。 エクストラクションがまだ失敗する場合（通常はページがログイン状態を必要とする場合、X/Twitter、Zhihu など）、ユーザーにデバッグポートを有効化してログイン済みセッションを複製するよう提示できます：open -na "Google Chrome" --args --remote-debugging-port=9222

• source_category=manual_only の場合 → アダプタを呼び出さず、fallback_hint を直接使用します
• adapter_name=wechat-article-to-markdown の場合 → wechat-article-to-markdown "<URL>" を実行します
• adapter_name=youtube-transcript の場合 → youtube-transcript を呼び出します
• adapter_name=baoyu-url-to-markdown の場合 → baoyu-url-to-markdown を呼び出します

ローカルファイル：

• bash ${SKILL_DIR}/scripts/source-registry.sh match-file "<path>" を統一的に使用します
• マッチ後、アダプタを呼び出さず直接読み込みます

純テキスト貼り付け：

• plain_text として統一的に扱います
• ユーザーが提供したテキストを直接使用します

統一的フォールバック規則：

• 自動エクストラクション結果について、bash ${SKILL_DIR}/scripts/adapter-state.sh classify-run <source_id> <exit_code> <output_path> を統一的に実行します
• classify-run の 8 列結果から state、detail、recovery_action、fallback_hint を読んでください
• runtime_failed を返す場合 → detail、recovery_action、fallback_hint に従ってユーザーに「このエクストラクションは失敗しましたが、一度再試行できます。うまくいかなければ手動エントリに切り替えてください」と説明します
• empty_result を返す場合 → detail、recovery_action、fallback_hint に従ってユーザーに「自動エクストラクションは有効な本文を取得できませんでした。テキストを手動で補完してから続行してください」と説明します
• その他の状態も同じ返却結果を使用し、二つ目のフォールバック文案を手書きしません

コンテンツ段階処理

素材の長さと情報密度に基づいて自動的に処理レベルを選択します：

判定基準：

• 素材コンテンツ > 1000 字 → 完全処理
• 素材コンテンツ <= 1000 字（短いツイート、小紅書ノートなど）→ 簡略処理

完全処理フロー（長素材 > 1000 字）

1. 素材コンテンツを抽出：上記のルーティングに従って素材テキストを取得します

2. 原始素材を raw/ 対応ディレクトリに保存：

   • 素材タイプに基づいて対応ディレクトリに保存（articles/、tweets/、wechat/、xiaohongshu/、zhihu/ など）
   • ファイル名形式：{日付}-{短いタイトル}.md
   • URL 類素材の場合、ファイルヘッダーに元の URL を記録します

   画像検出と追跡：素材を保存した後、コンテンツで画像参照が含まれているかを扫描します（![ または <img または .png/.jpg/.gif/.svg URL）。画像が検出された場合：

   • ユーザーに通知：「素材は {N} 個の画像参照を含んでいます。画像リンクが失効する可能性があります。raw/assets/（Obsidian ユーザーは設定で添付ファイル一括ダウンロードのキーボードショートカットを設定できます）に手動でダウンロードすることをお勧めします」
   • 後続の source ページの frontmatter で：
     • images：検出された画像参照の数を記録します
     • image_paths：ユーザーが既に画像を raw/assets/ にダウンロードしている場合、YAML ブロックリスト形式でパスを記録します。ダウンロードされていない場合、空の配列 [] を保ちます。例：

       image_paths:
         - raw/assets/2026-01-15-fig1.png
         - raw/assets/2026-01-15-fig2.jpg
       

   • ingest フローをブロックしません。通知のみです
   • ユーザーが後で画像をダウンロード後、source ページの image_paths を手動で更新するか、次の lint 時に AI が補完を支援できます

3. コンテキストを読み取り：

   • 優先順序：purpose.md > .wiki-schema.md > index.md
   • purpose.md が存在する場合、中核目標、主要な質問、研究範囲を最初に読み取ります
   • purpose.md を使用して後続の実体、主題、関連性の取捨選択と重み付けを指導します

4. キャッシュチェック：

   • LLM 処理に入る前に、まず以下を実行します：

     bash ${SKILL_DIR}/scripts/cache.sh check "<raw ファイルパス>"
     

   • HIT または HIT(repaired) を返す場合 → このLLM 呼び出しをスキップし、既存の wiki ページを直接読み取り、ユーザーに「変化がなく、既存の結果を再利用する」と通知します
     • HIT(repaired) はキャッシュ