llm-wiki

llm-wiki — 個人ナレッジベース構築システム

断片的な情報を、継続的に蓄積され、相互にリンクされたナレッジベースに変えます。素材を提供するだけで、あとは AI がすべて整理します。

この skill でできること

llm-wiki は、成長し続ける個人ナレッジベースの構築を支援します。従来のノートアプリではなく、AI に管理を任せる wiki システムです。

• 素材（リンク、ファイル、テキスト）を渡すと、AI が重要な知識を抽出し、相互にリンクされた wiki ページに整理します
• 使うたびにナレッジベースがより充実し、毎回ゼロから始める必要がありません
• すべてローカルの Markdown ファイルなので、Obsidian や任意のエディターで閲覧できます

基本理念

従来の方法（RAG／チャット履歴）の問題点は、質問するたびに AI が元のファイルを最初から読み直し、知識が蓄積されないことです。ナレッジベースの価値は、知識を一度コンパイルし、その後も継続的にメンテナンスすることにあり、質問のたびに再度推論することではありません。

クイックスタート

ユーザーには次の 2 つを伝えるだけで十分です。

1. 初期化：「ナレッジベースを初期化して」と伝える
2. 素材の追加：リンクまたはファイルを渡し、「これを取り込んで」と伝える

---

Script Directory

スクリプトは scripts/ サブディレクトリにあります。

パスの解決：

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

---

依存関係の確認

中核となるワークフロー（ローカルファイル、プレーンテキスト、既存のナレッジベースの操作）では、通常、これらの抽出依存関係は必要ありません。

ユーザーが URL の形式で素材を提供し、ウェブページ／X／WeChat 公式アカウント／YouTube／知乎のコンテンツを自動抽出するよう明示的に求めた場合に限り、次のオプション依存関係を確認します。

不足している場合は、ユーザーに次を実行するよう案内します。

bash ${SKILL_DIR}/install.sh --platform <当前平台> --with-optional-adapters

オプションの依存関係 skill／ツール：

• baoyu-url-to-markdown — 通常のウェブページ、X/Twitter、一部の知乎コンテンツの抽出
• wechat-article-to-markdown — WeChat 公式アカウントの記事の抽出
• youtube-transcript — YouTube 字幕の抽出

これらの依存関係が不足していても、skill は引き続き利用できます（ユーザーはローカルファイルを直接提供する、テキストを貼り付ける、または手動の方法に切り替えることができます）。

外部連携の状態モデル

外部連携の失敗は、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：今回の抽出処理が失敗したことを説明します。一度再試行した後、手動の方法に切り替えられます
• 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 のレビュー」「digest XX」	→ digest
「X と Y を比較して」「X と Y を比べて」「時系列を整理して」「時系列順に並べて」	→ digest（指定形式）
「ナレッジベースをチェック」「ヘルスチェック」「lint」	→ lint
「ナレッジベースの状態」「今あるもの」「素材はいくつある」	→ status
「ナレッジグラフを描いて」「関連図を見せて」「graph」「ナレッジベースのマップ」	→ graph
「素材を削除」「remove」「delete source」「削除」	→ delete
「結晶化」「crystallize」「これをナレッジベースに記録して」「この会話を要約して」	→ 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、公众号、知乎等）
   - 小红书内容请直接粘贴文本给我（暂不支持自动提取）
   - 给我一个本地文件路径（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，提示用户清理后再来
• 其他不明确的回复 → 再问一次，最多两次；两次都不是明确 y/n 则终止
• 绕过规则：如果用户在当前对话里已经明确说过"素材里没有敏感信息，直接开始"， 或者用户是在 batch-ingest 流程中（已经在顶层确认过一次），AI 可以跳过这一步

为什么是自查清单而不是脚本：

• 正则在非结构化文本（聊天记录、笔记）里误报率很高，错过真的敏感词，误报无害的普通词
• 把判断权还给用户，比让脚本决定更可靠
• 对新手更友好，不会遇到看不懂的脚本报错

素材の抽出ルーティング

素材の種類に応じて、最適な抽出方法へ自動的にルーティングします。

外部アダプターを使う前の確認：

• 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、知乎など、ページにログイン状態が必要な場合）は、ログイン済みセッションを再利用するため、デバッグポートを有効にするようユーザーに案内できます：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 に従って、「自動抽出で有効な本文を取得できませんでした。本文を手動で補ってから続行してください」とユーザーに伝えます
• その他の状態でも、同じ結果を使用し、2 つ目のフォールバック文面を独自に作成しません

コンテンツの処理レベル

素材の長さと情報密度に応じて、処理レベルを自動的に選択します。

判定基準：

• 素材の内容が 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) は、キャッシュの自己修復に成功したことを示します（前回の update はスキップされましたが、source ページが存在し、source_path が一致しています）
   • MISS:<reason> が返された場合 → 以下の 2 ステップのフローを続行します
     • MISS:no_entry — この素材の初回処理です（通常の状態）
     • MISS:hash_changed — 素材の内容が変更されているため、再処理が必要です
     • MISS:no_source — キャッシュ記録はありますが、source ページが削除されています
     • MISS:repaired_needs_verify — 同名の source ページが見つかりましたが、source_path が一致しないため、関連付けが正しいことを確認するために再処理が必要です

5. Step 1：構造化分析：

   • 入力：元の内容 + purpose.md + 既存の wiki 構造（少なくとも index.md の概要を読み取ります）
   • 出力：JSON 形式の分析結果。永続化せず、現在の ingest フロー内で一時的に渡します
   • JSON には少なくとも entities、topics、connections を含めます
   • confidence は必須フィールドです。欠落している場合は形式異常とみなし、単一ステップのフォールバックを実行します

   {
     "source_summary": "一句话概括",
     "entities": [{"name": "xxx", "type": "concept", "relevance": "high", "confidence": "EXTRACTED", "evidence": "原文摘录或推理依据"}],
     "topics": [{"name": "xxx", "importance": "high"}],
     "connections": [{"from": "A", "to": "B", "type": "因果", "confidence": "INFERRED", "evidence": "推理依据"}],
     "contradictions": [{"claim_a": "...", "claim_b": "...", "context": "..."}],
     "new_vs_existing": {"new_entities": [], "updates": []}
   }
   

   信頼度付与ルール（Claude が必ず遵守）：

   • EXTRACTED：情報が原文に直接現れており、字面で見つけられる。evidence フィールドに原文の抜粋を提供すべき（推奨 ≤50 字）。欠落している場合、スクリプトは WARN を出しますがブロックはしません
   • INFERRED：情報が複数の原文から推論されたもので、原文に直接書かれていない。evidence フィールドに推論の根拠を説明すべき。欠落している場合、スクリプトは WARN を出しますがブロックはしません
   • AMBIGUOUS：原文の記述が不明確、または曖昧である。evidence は任意
   • UNVERIFIED：情報が Claude の背景知識に由来し、原文に証拠がない。evidence は任意

   Step 1 完了後、必ず検証を実行します：

   1. mkdir -p {wiki_root}/.wiki-tmp
   2. Step 1 の JSON を {wiki_root}/.wiki-tmp/step1-latest.json に書き込みます
   3. bash ${SKILL_DIR}/scripts/validate-step1.sh {wiki_root}/.wiki-tmp/step1-latest.json を呼び出します
   4. 検証完了後に {wiki_root}/.wiki-tmp/step1-latest.json を削除します

   スクリプトが非 0 を返した場合、自動的に単一ステップの ingest にフォールバックします（Step 2 は行いません）。

6. Step 2：ページ生成：

   • 入力：元の内容 + purpose.md + Step 1 の分析結果 + 既存の関連 wiki ページ
   • コンテキスト読み込みルール：Step 1 の new_vs_existing.updates に列挙された既存ページのみを読み込みます。あるページが 2000 字を超える場合は、frontmatter + 更新が必要なセクションのみを読み込みます
   • 出力：作成または更新が必要なすべての wiki ページの内容
   • Step 2 は、元のフローにおける素材サマリー、エンティティページ、トピックページ、index、log の更新を担当します

7. フォールバック：

   • Step 1 が有効な JSON でない場合、または entities、topics、confidence などの必須フィールドが欠落している場合、自動的に元の単一ステップフローにフォールバックします
   • フォールバック時、今回新規生成されたすべての内容に一律で以下を付加します：

   • 同時にページ上部にコメントを追加し、今回の処理がフォーマットの問題で降格されたことを説明し、「一部に注釈があり、一部にない」状態を避けます

8. 素材サマリーページを生成（wiki/sources/{日期}-{短标题}.md）：

   • templates/source-template.md の形式を参考にします
   • frontmatter に sources: [] フィールドを保持します。今回の ingest に明確な出典がある場合は、実際の raw/source 参照に従って記入します
   • 含める内容：基本情報、中核となる主張、重要概念、他の素材との関連、原文の優れた抜粋
   • Step 1 で INFERRED または AMBIGUOUS とマークされた関係について、HTML コメントで信頼度を保持します：

   • source ページを書き込む際は、必ず create-source-page.sh を使用します（キャッシュを自動更新）：

     # 先把页面内容写到临时文件
     echo "<页面内容>" > /tmp/source-content.tmp
     # 调用脚本原子写入 + 缓存更新
     bash ${SKILL_DIR}/scripts/create-source-page.sh "<raw 文件路径>" "wiki/sources/{日期}-{短标题}.md" /tmp/source-content.tmp
     

   • スクリプトが SUCCESS を返した場合 → 書き込みとキャッシュの両方が更新されています
   • スクリプトが ERROR を返した場合 → 書き込みまたはキャッシュが失敗しています。エラーメッセージを確認して再試行します

9. エンティティページを更新または作成（wiki/entities/）：

   • 各重要概念について、wiki/entities/ 下に対応するページが既にあるか確認します
   • 既にある場合 → 新しい情報を追記し、「異なる素材における見解」セクションを更新します
   • ない場合 → 新しいエンティティページを作成します。templates/entity-template.md を参考にします
   • [[实体名]] 構文で双方向リンクを作成します

10. トピックページを更新または作成（wiki/topics/）：

• 素材が扱う主要な研究テーマを識別します
• 対応するトピックページが既にある場合 → 素材サマリー表と中核となる主張を更新します
• ない場合 → 新しいトピックページを作成します。templates/topic-template.md を参考にします

11. index.md を更新：

• 対応するカテゴリの下に新しいエントリを追加します
• 概要の統計数値を更新します

12. log.md を更新：

• log.md の追記形式：## {日期} ingest | {素材标题}
• 追加および更新したページのリストを記録します
• 注意：キャッシュの更新は Step 8 で create-source-page.sh により自動的に完了しているため、ここで cache.sh update を再度呼び出す必要はありません

13. ユーザーに結果を表示（WIKI_LANG に応じて言語を切り替え）：

中国語（zh）：

已消化：{素材标题}

新增页面：
- {素材摘要页}
- {新实体页1}
- {新主题页1}

更新页面：
- {已有实体页2}（追加了新信息）

发现关联：
- 这篇素材和 [[已有素材]] 在 {某概念} 上有联系

别名建议：（仅当发现新的同义词关系时显示）
- 建议添加到别名词表：{术语A} = {术语B}

（英語版は「出力言語ルール」に従って生成、構造は同じ。）

簡易処理フロー（短い素材 <= 1000 字）

短いツイート、小紅書のノート、短いコメントなどに適用されます。

1. 元の素材を保存 対応する raw/ ディレクトリへ

   • 画像の検出と追跡：完全な処理フローと同じく、画像参照をスキャンしてユーザーに通知します。source ページの images および image_paths frontmatter フィールドに数とパスを記録します

2. コンテキストを読み込み、キャッシュを確認：

   • 引き続き purpose.md を優先的に読み込みます
   • 引き続き先に bash ${SKILL_DIR}/scripts/cache.sh check "<raw 文件路径>" を実行します
   • キャッシュがヒットした場合（HIT または HIT(repaired)）、既存の結果をそのまま再利用します

3. 簡易サマリーページを生成（wiki/sources/）：

   • frontmatter に sources: [] を書き込みます
   • 基本情報と中核となる主張のみを含めます
   • 「原文の優れた抜粋」セクションは書きません
   • source ページを書き込む際は同様に create-source-page.sh を使用します（キャッシュを自動更新）

4. 1〜3 個の重要概念を抽出：

   • 対応するエンティティページが既に存在する場合 → 一文の説明を追記します
   • 存在しない場合 → サマリーページ内で [待创建: [[概念名]]] とマークします

5. index.md と log.md を更新（キャッシュは create-source-page.sh により自動更新済み）

6. スキップ：トピックページの作成/更新、overview の更新

7. ユーザーに簡易結果を表示（WIKI_LANG に応じて言語を切り替え）：

   中国語（zh）：

   已消化：{素材标题}（短内容，简化处理）
   
   新增：
   - 素材摘要页
   
   待完善：
   - [待创建: [[概念名]]]（积累更多素材后整理）
   

   （英語版は「出力言語ルール」に従って生成、構造は同じ。）

---

ワークフロー 3：batch-ingest（バッチ消化）

ユーザーがフォルダパスを渡した場合、または「これらを全部整理して」と言った場合。

ステップ

1. ナレッジベースのパスを確認：

   • 共通事前チェック（上記の定義を参照）を実行し、ナレッジベースのルートパスと WIKI_LANG を取得します

2. 処理可能なすべてのファイルを列挙：

   • 対応フォーマット：.md, .txt, .pdf, .html
   • 無視：隠しファイル、.git ディレクトリ、node_modules など

3. ファイルリストを表示 し、処理範囲を確認します（WIKI_LANG に応じて言語を切り替え）：

   zh：

   发现 {N} 个文件待处理：
   1. file1.pdf
   2. file2.md
   3. file3.txt
   
   预计需要 {N} 轮处理。是否开始？
   

   （英語版は「出力言語ルール」に従って生成、構造は同じ。）

4. 1 つずつ処理：各ファイルに対して ingest ワークフローを実行します

   • 各ファイルで先に cache check を実行します
   • キャッシュがヒットしたファイルはそのままスキップし、LLM 処理には進みません
   • MISS のファイルのみ、完全または簡易処理を続行します

5. 5 ファイルごとに一時停止 し、進捗を表示して続行するか尋ねます（WIKI_LANG に応じて言語を切り替え）：

   zh：

   进度：5/{N} 已完成
   
   本批处理结果：
   - 新增素材摘要：5
   - 新增实体页：3
   - 更新已有页面：7
   
   继续处理剩余 {M} 个文件？
   

   （英語版は「出力言語ルール」に従って生成、構造は同じ。）

6. すべて完了後：

   • index.md の全量更新を一度実行します
   • サマリーレポートを出力します（WIKI_LANG に応じて言語を切り替え）：

   zh：

   批量消化完成！
   
   处理了 {N} 个文件：
   - 已跳过 N 个（无变化），处理 M 个（新增/更新）
   - 成功：{S}
   - 跳过（内容为空/格式不支持）：{K}
   - 失败：{F}
   
   新增页面：{total_new}
   更新页面：{total_updated}
   

   （英語版は「出力言語ルール」に従って生成、構造は同じ。）

---

ワークフロー 4：query（ナレッジベースの照会）

手順

1. ナレッジベースのパスを確認する：

   • 共通の事前チェック（上記の定義を参照）を実行し、ナレッジベースのルートパスと WIKI_LANG を取得します
   • 利用可能なナレッジベースがない場合は、先に初期化するようユーザーに案内します

2. index.md を読み、ナレッジベースの全体像を把握します

3. 関連ページを検索する：

   • エイリアスの展開：まず .wiki-schema.md の「エイリアス用語集」を読みます。ユーザーの検索キーワードがいずれかのエイリアスグループに一致した場合は、そのグループの同義語をすべて検索対象に含めます（例：「LLM」を検索する場合は、「大規模言語モデル」と「大規模モデル」も同時に検索します）
     • 展開ルール：一致したグループ内でのみ展開し、グループをまたいで連鎖させません（A=B と B=C が別のグループの場合、A の検索では最初のグループだけを展開し、2 番目のグループとは統合しません）
     • 重複排除：展開後のキーワードリストは自動的に重複排除し、空項目と空白のみの項目は無視します
   • 展開後のすべてのキーワードを使って、index.md 内から関連するカテゴリと項目を特定します
   • 次に、wiki/ ディレクトリ内で Grep を使ってすべてのキーワードを検索します（元のキーワード＋エイリアス展開後のキーワード）
   • 関連度順に並べ替えます：ファイル名の完全一致 > index.md の項目との一致 > 本文でのキーワード出現回数（同じエイリアスグループの複数の語が同じページに出現しても 1 回として数え、エイリアスが多く含まれるページのスコアが不当に高くなるのを防ぎます）
   • 段落数の上限：展開後の各キーワードについて、該当する段落は最大 3 件までとし、段落の合計は 15 件を超えないようにします
   • 最も関連性の高い 3～5 ページを読みます
   • 1 ページあたりの長さの上限：ページが 2000 字を超える場合は、frontmatter＋先頭 500 字＋Grep の該当段落（前後各 3 行）のみを読み、長いページでコンテキストを使いすぎないようにします

4. 回答をまとめる：

   • WIKI_LANG に従い、対応する言語でユーザーの質問に回答します
   • 情報源を明記します（wiki ページを [[ページ名]] 形式で引用します）
   • 複数の資料で見解が異なる場合は、それぞれ分けて記載し、情報源を明記します

5. 永続化する価値があるか判断する：

   • 回答が 3 件以上の情報源を引用した総合分析である場合は、ユーザーに「この回答をナレッジベースに保存しますか？」と尋ねます
   • 情報源が 3 件未満の場合は、デフォルトでその場限りの回答とし、永続化を積極的に提案しません

6. 重複を検出する：

   • 永続化の前に、wiki/queries/ 内で同じテーマのページを検索します
   • frontmatter の tags と title を照合し、同じテーマの query ページがすでに存在するか判断します
   • すでに存在する場合は、「既存のページを更新」するか「新しいページを作成」するかユーザーに尋ねます
   • ユーザーが既存ページの更新を選んだ場合は、古いページに superseded-by マークを追加します

7. query ページを保存する：

   • templates/query-template.md を使ってページを生成します
   • 同じテーマでのファイル名の競合を避けるため、保存先には wiki/queries/{date}-{short-hash}.md を使用します
   • frontmatter には type: query と derived: true を必ず含めます
   • derived: true は、これが派生コンテンツであり、一次資料ではないことを示します

8. 自己参照を防止する：

   • 以降の ingest 分析では、query ページを二次情報源として扱い、主要な知識情報源にはしません
   • 後続のページが query ページ内の情報を引用する場合、関連する関係はすべて INFERRED として扱います
   • ingest では wiki/queries/ を積極的にスキャンしません。現在の質問で本当に必要な場合に限り、query ページを補足資料として読みます

9. インデックスとログを更新する：

   • 保存に成功したら、index.md に query 項目を追加します
   • 同時に log.md に query の保存記録を 1 件追加します

---

ワークフロー 5：lint（ヘルスチェック）

実行タイミング

• ユーザーが「ナレッジベースをチェックして」と明示的に依頼したとき
• ingest のたびに、素材の合計数が 10 の倍数であれば、lint の実行を積極的に提案します

事前チェック

共通の事前チェック（上記の定義を参照）を実行します。利用可能なナレッジベースがない場合は、先に初期化するようユーザーに案内します。

1. チェック範囲を決める：

   • 最近更新された 10 ページ（ファイルの変更日時順）
   • ランダムに抽出した 10 ページ（古いページの問題を見落とさないため）
   • ページの合計数が 20 以下の場合は、すべてをチェックします

2. Step 0：スクリプトを呼び出して機械的チェックを行う（必ず最初に実行し、省略しないでください）：

   bash ${SKILL_DIR}/scripts/lint-runner.sh <wiki_root>
   

   スクリプトは一度の読み込みで、孤立ページ、index、画像、情報源、すべての wikilink をまとめてチェックします。明示的なパスと一意なベア名は実際のページパスとして解決され、同名のページは統合されません。曖昧なリンクはリンク先を推測せず、関係にも含めません。候補をすべて一覧表示し、「作成待ち」と実際のリンク切れは分けて報告します。また、コード例をリンクとして扱いません。

   通常のチェックは読み取りのみを行い、データの問題をすべて報告して終了コード 0 を返します。パス、引数、解析、読み込みに失敗した場合は 1 を返します。曖昧なリンク、実際のリンク切れ、パスの競合によって CI を失敗させる場合は、明示的に次を実行します：

   bash ${SKILL_DIR}/scripts/lint-runner.sh <wiki_root> --strict
   

   厳格モードでは、レポートの完了後、error がある場合は 2 を返し、「作成待ち」などの通知だけの場合は 0 を返します。末尾に --json を追加すると、同じ内容の完全な構造化レポートを取得できます。これらのチェックはいずれも、ナレッジベースの Markdown を変更しません。

3. 項目ごとにチェックする（AI による判断が必要なため、スクリプトでは実行できません）：

   矛盾する情報（関連ページを読み、互いに矛盾する記述がないか確認します）：

   • 見つかった矛盾を列挙します
   • 各矛盾の情報源となるページを明記します

   相互参照の不足（関連するテーマのページ同士に相互リンクを追加すべきか確認します）：

   • 追加を提案する相互参照

   信頼度レポート（EXTRACTED / INFERRED / AMBIGUOUS / UNVERIFIED を集計します）：

   • AMBIGUOUS の項目を強調し、優先的に検証するようユーザーに促します
   • EXTRACTED とマークされた項目を抜き取りでチェックし、元の素材で対応する原文を見つけられるか確認します
   • EXTRACTED の情報を原文までさかのぼれないことが判明した場合は、より低い信頼度に戻すか、再整理するようユーザーに案内します

   補足の提案：Step 0 のスクリプトによる孤立ページ／リンク切れの出力を基に、修正案を提示します（スクリプトは問題を列挙するだけで、解決策は提示しません）

   • 孤立ページ → どの関連ページに [[リンク]] を追加するか提案します
   • リンク切れ → どの概念の新しいページを作成するか、または既存のページへの参照に書き換えるか提案します

4. レポートを出力する（WIKI_LANG に従って言語を切り替え、Step 0 のスクリプト出力と Step 3 の AI による判断結果をまとめます）：

   zh：

   知识库健康检查报告
   
   检查范围：最近更新 10 页 + 随机抽查 10 页（共 {N} 页）
   
   孤立页面（没有其他页面链接到它）：
   - [[某页面]] → 建议从 [[相关页面]] 添加链接
   
   断链（被链接但不存在）：
   - [[某概念]] → 建议创建新页面
   
   矛盾信息：
   - 关于"XX"，[[页面A]] 说是 Y，但 [[页面B]] 说是 Z
   
   缺失索引：
   - {文件名} 存在但未记录在 index.md 中
   
   置信度报告：
   - EXTRACTED：{N}
   - INFERRED：{N}
   - AMBIGUOUS：{N}
   - UNVERIFIED：{N}
   

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

5. ユーザーに尋ねる：どの問題を自動修正しますか？（WIKI_LANG に従い、対応する言語で質問します）

---

ワークフロー 6：status（状態の確認）

事前チェック

共通の事前チェック（上記の定義を参照）を実行します。利用可能なナレッジベースがない場合は、先に初期化するようユーザーに案内します。

手順

1. まず bash ${SKILL_DIR}/scripts/source-registry.sh list を実行して、情報源の一覧を読み込みます

2. ナレッジベースのパスを取得します（上記の CWD チェックロジックに従います）

3. 次の項目を集計します：

   • 情報源一覧の source_label と raw_dir に従って、raw/ 内のファイル数を項目ごとに集計します
   • wiki/entities/ 内のページ数
   • wiki/topics/ 内のページ数
   • wiki/sources/ 内のページ数
   • wiki/comparisons/ と wiki/synthesis/ 内のページ数
   • purpose.md が存在するかどうか

4. log.md の最後の 5 件の記録を読みます

5. index.md を読み、テーマの概要を取得します

6. bash ${SKILL_DIR}/scripts/adapter-state.sh summary-human を実行し、アダプターの状態を取得します

7. node ${SKILL_DIR}/scripts/source-signal-coverage.js <wiki_root> を実行して情報源シグナルのカバレッジデータを取得し、返された JSON の summary から次を読み取ります：

   • ok（使用済み）、missing_sources（sources がない）、empty_sources（sources が空）、invalid_sources（形式が無効）、not_applicable（現在は対象外）

8. レポートを出力する（WIKI_LANG に従って言語を切り替えます）：

   zh：

   知识库状态：{主题}
   
   素材分布（按来源总表）：
   - {source_label}：{N}
   - {source_label}：{N}
   ...
   
   Wiki 页面：{总数} 页
     - 实体页：{N}
     - 主题页：{N}
     - 素材摘要：{N}
     - 对比分析：{N}
     - 综合分析：{N}
   
   图谱来源信号覆盖：
   - 已参与：{ok}
   - 缺少 sources：{missing_sources}
   - sources 为空：{empty_sources}
   - 格式无效：{invalid_sources}
   - 当前不参与：{not_applicable}
   
   研究方向：
   - purpose.md 是否存在：{是/否}
   
   最近活动：
   - {日期} ingest | {素材标题}
   - {日期} ingest | {素材标题}
   ...
   
   外挂状态：
   {summary-human 原文}
   
   建议：
   - 你可能想深入了解 {某主题}，已有 {N} 篇相关素材
   - {某实体} 被 {N} 篇素材提到，值得整理成独立页面
   

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

   アダプターの状態には bash ${SKILL_DIR}/scripts/adapter-state.sh summary-human の出力をそのまま使用し、独自に情報源一覧を書き直さないでください。

---

ワークフロー 7：digest（詳細な総合レポート）

query との違い：query はすばやく質問に回答し、新しいページは作成しません。digest は複数の素材を詳細に総合し、永続化するレポートを生成します。

トリガーとなるキーワード

• デフォルトの詳細レポート形式：「XX について教えて」、「XX を詳しく分析して」、「XX のレビュー」、「XX を digest して」、「XX を包括的にまとめて」
• 比較表形式：「X と Y を比較して」、「X と Y を比べて」、「X と Y の違いは何ですか」
• タイムライン形式：「タイムラインをまとめて」、「時系列順に並べて」、「時系列で」

前置检查

执行通用前置检查（见上方定义）。如果没有可用知识库，提示用户先初始化。

1. 搜索相关页面：

   • 别名展开：同 query 工作流，先读取 .wiki-schema.md 中的"别名词表"展开同义词（不跨组传递，自动去重）
   • 用 Grep 在 wiki/ 下搜索所有关键词（原始 + 别名展开），同一别名组命中同一页面只计一次
   • 列出将要综合的页面（让用户了解报告覆盖范围）

2. 深度阅读所有相关页面 + 选择输出格式：

   • 读取找到的所有相关 wiki 页面（sources/、entities/、topics/）
   • 单页长度上限：如果某页超过 3000 字，优先读取 frontmatter + 核心观点章节 + 与主题直接相关的段落，跳过"原文精彩摘录"等冗长引用部分
   • 归纳每个页面的核心观点和来源信息
   • 根据触发关键词决定输出格式：
     • 用户说"对比"/"比较"类 → 使用对比表格式（见下方模板 B）
     • 用户说"时间线"/"按时间"类 → 使用时间线格式（见下方模板 C）
     • 其他默认 → 使用深度报告格式（见下方模板 A）

3. 生成结构化深度报告，保存到 wiki/synthesis/{主题}-{格式}.md（按 WIKI_LANG 切换语言）：

   文件名规则：默认格式用 {主题}-深度报告.md，对比表用 {主题}-对比.md，时间线用 {主题}-时间线.md

   模板 A：深度报告格式（默认）

   zh：

   # {主题} 深度报告
   
   > 综合自 {N} 篇素材 | 生成日期：{日期}
   
   ## 背景概述
   （简要说明这个主题的背景和重要性）
   
   ## 核心观点
   （按重要性排列，每个观点标注来源）
   - 观点一（来源：[[素材A]]、[[素材B]]）
   - 观点二（来源：[[素材C]]）
   
   ## 不同视角对比
   （如有多个素材观点不同，在此对比）
   | 维度 | 来源A的观点 | 来源B的观点 |
   |------|------------|------------|
   
   ## 知识脉络
   （按时间或逻辑顺序梳理该主题的发展）
   
   ## 尚待解决的问题
   （现有素材中尚未回答的问题，可作为下次搜集素材的方向）
   
   ## 相关页面
   （列出所有综合来源的链接）
   

   （英文版按「输出语言规则」生成，结构相同。）

   模板 B：对比表格式（触发词：对比 / 比较）

   # {对比主题} 对比分析
   
   > 对比 {N} 个对象 | 生成日期：{日期}
   
   ## 对比对象
   - [[对象 A]]
   - [[对象 B]]
   - [[对象 C]]（如有）
   
   ## 对比表
   
   | 维度       | [[对象 A]] | [[对象 B]] | [[对象 C]] |
   |-----------|-----------|-----------|-----------|
   | 核心观点   | ...       | ...       | ...       |
   | 适用场景   | ...       | ...       | ...       |
   | 优点       | ...       | ...       | ...       |
   | 缺点 / 限制 | ...       | ...       | ...       |
   | 来源素材   | [[素材1]] | [[素材2]] | [[素材3]] |
   
   ## 关键差异
   （用 1-2 句话说清最重要的差异点）
   
   ## 相关页面
   

   模板 C：时间线格式（触发词：时间线 / 按时间）

   # {主题} 时间线
   
   > 时间跨度：{起始年} ~ {结束年} | 生成日期：{日期}
   
   ```mermaid
   gantt
     title {主题} 时间线
     dateFormat YYYY-MM-DD
     section 主要事件
       事件 A : 2023-01-01, 1d
       事件 B : 2024-03-15, 1d
       事件 C : 2025-06-20, 1d
   

   事件说明

   • 2023-01-01 — 事件 A：简要说明（来源：[[素材A]]）
   • 2024-03-15 — 事件 B：简要说明（来源：[[素材B]]）
   • 2025-06-20 — 事件 C：简要说明（来源：[[素材C]]）

   相关页面

   
   > **时间线格式注意事项**：
   > - `gantt` 要求 `YYYY-MM-DD` 精度
   > - 如果素材只有年份（如 "2023 年"），把日期补为该年第一天（`2023-01-01`）
   > - 如果连年份都不确定，改用**纯文字时间线**（无序列表按时间排序），不用 Mermaid gantt
   > - 如果事件超过 15 个，建议按 section 分组，避免图太长
   
   

4. 更新 index.md 和 log.md：

   • index.md 的"综合分析"分类下添加新报告条目
   • log.md 追加：## {日期} digest | {主题}

5. 向用户展示结果（按 WIKI_LANG 切换语言）：

   zh：

   已生成深度报告：{主题}
   
   综合了 {N} 篇素材：
   - [[素材1]]、[[素材2]]...
   
   报告已保存：wiki/synthesis/{主题}-深度报告.md
   
   发现这些待解决问题，可以继续搜集素材：
   - {问题1}
   - {问题2}
   

   （英文版按「输出语言规则」生成，结构相同。）

---

工作流 8：graph（知识图谱 · Mermaid + 交互式 HTML）

触发关键词

"画个知识图谱"、"看看关联图"、"graph"、"知识库地图"、"展示知识关联"

前置检查

执行通用前置检查（见上方定义）。如果没有可用知识库，提示用户先初始化。

1. 扫描双向链接：

   • 遍历 wiki/ 下所有 .md 文件
   • 提取每个文件中的 [[链接]] 语法，建立关系列表：页面A → 页面B

2. 生成 Mermaid 图表文件 wiki/knowledge-graph.md：

   # 知识图谱
   
   > 自动生成 | {日期} | 共 {N} 个节点，{M} 条关联
   
   ```mermaid
   graph LR
     A[概念1] --> B[概念2]
     A --> C[素材1]
     D[主题1] --> A
     D --> E[概念3]
   ```
   
   查看方式：用 Typora、VS Code（Markdown Preview Enhanced）、或直接在 GitHub 上查看。
   

   生成规则：

   • 节点名用中括号 [名称]，名称太长则截断到 10 字
   • 只展示有双向链接关系的节点（孤立节点不纳入图谱）
   • 如果关系超过 50 条，只保留被引用次数最多的 30 个节点，避免图谱过于密集
   • 默认全部使用 A --> B 无标注箭头，不自动判断关系类型

   可选：手动美化图谱（生成后由用户自己做，AI 不自动处理）：

   生成的 wiki/knowledge-graph.md 默认只有 --> 箭头。如果用户希望图谱更清楚地 表达关系类型，可以：

   1. 用编辑器打开 wiki/knowledge-graph.md
   2. 参考 .wiki-schema.md 里的"关系类型词汇表"（实现 / 依赖 / 对比 / 矛盾 / 衍生）
   3. 把最重要的 3-5 条箭头改写成 A -->|实现| B 之类的带标注写法
   4. 保存后用 Obsidian / VS Code / Typora 重新渲染

   AI 在 graph 工作流里不自动打标——因为自动判断关系类型需要额外阅读整段上下文， 成本高且准确率难保证。人类对"哪些关系最值得打标"的判断更可靠。 用户如果明确要求 AI 给某几条边打标，可以单独说"把 A 和 B 之间的关系标成'实现'"， AI 再手动修改 wiki/knowledge-graph.md 对应的那一行。

2b. 生成交互式图谱数据（wiki/graph-data.json）：

bash scripts/build-graph-data.sh "$WIKI_ROOT"

脚本会递归扫描 wiki/{entities,topics,sources,comparisons,synthesis,queries}/**/*.md， 解析 wikilink 与 `` 注释， 调用本地 Node helper 计算 3 信号边权重（共引强度 / 来源重叠 / 类型亲和度）、Louvain 社区和规则 insights， 并把 wiki/graph-data.json 与同目录唯一的 wiki/graph-warnings.json 成对写入（内容 >2MB 自动降级，单节点只留 500 行；图规模超预算时 insights 自动降级）。节点身份使用实际知识库相对路径，因此六类正式目录中的同名页面都会保留。明确路径和唯一裸名正常建边；歧义链接不建边并报告候选；“待创建”和真正断链分别报告。

正常构建即使发现数据问题也返回 0，只有工具、输入或写入失败返回 1，并且绝不修改 Markdown。CI 要阻断数据错误时，另运行 node scripts/wiki-link-cli.js check "$WIKI_ROOT" --strict；严格检查有 error 返回 2。自定义输出必须仍在知识库内、文件名保持 graph-data.json，并使用自己的目录；该目录中的 graph-warnings.json 是它唯一的配对详情文件，两个自定义输出要放在两个不同目录。 依赖 jq + node（如缺失可运行 brew install jq node）。

2c. 图谱运行时说明：

• 图谱基础构建现在依赖 jq + node
• 不需要额外 npm install
• node 只用于运行随仓库分发的本地预构建 helper

2d. 生成交互式图谱 HTML（东方编辑部 × 数字山水风）：

bash scripts/build-graph-html.sh "$WIKI_ROOT"

生成 wiki/knowledge-graph.html。脚本会先验证成对告警，再安全内嵌图谱和最多 2 MiB（gzip level 9）的告警详情，离线双击即可打开。详情超过上限时会稳定精简并保留全部总数；详情缺失或与图谱不是同一代时仍显示图谱，并提示重新构建。 页面保持三栏国风布局：左侧文献索引，中间数字山水图谱，右侧常驻节点详情。 包含搜索、社区筛选、节点视觉分层、首屏推荐预览、摘要、正文、相邻节点、洞察、小地图和关系置信度图例。 离线页只负责解释告警，不提供改名、解决或其他写入操作。

3. 读取 insights 并向用户展示结果（按 WIKI_LANG 切换语言）：

   先读取 insights：

   jq '.insights' "$WIKI_ROOT/wiki/graph-data.json"
   

   zh：

   知识图谱已生成！
   
   共 {N} 个节点，{M} 条关联
   
   图谱洞察：
   - 惊人连接：{from} ↔ {to}（跨社区，权重 {weight}）{如有}
   - 桥节点：{node}（连接 {count} 个社区）{如有}
   - 知识缺口：{node}（度数 {degree}，建议补充素材）{如有}
   - 稀疏社区：{community}（密度 {density}）{如有}
   
   查看方式：
   - 交互式（推荐）：双击 wiki/knowledge-graph.html
     （建议 Chrome / Firefox；Safari 若提示"已阻止脚本"，
      可在 wiki/ 下跑 `python3 -m http.server 8000` 再访问）
   - Mermaid 静态图：wiki/knowledge-graph.md
     （Obsidian / VS Code Markdown Preview Enhanced / GitHub / Typora 均可渲染）
   
   孤立页面（未纳入图谱）：
   - [[某页面]]（建议添加到相关实体页或主题页）
   

   （英文版按「输出语言规则」生成，结构相同。各洞察类别为空时省略该行。）

---

工作流 9：delete（删除素材）

触发关键词

"删除素材"、"remove"、"delete source"、"移除"

前置检查

执行通用前置检查（见上方定义）。如果没有可用知识库，提示用户先初始化。

步骤

1. 识别目标素材：

   • 在 raw/ 下搜索用户提到的素材名
   • 如果匹配到多个候选，先列出候选文件让用户确认

2. 扫描影响范围：

   • 先运行：

     bash ${SKILL_DIR}/scripts/delete-helper.sh scan-refs "<wiki 根目录>" "<素材文件名>"
     

   • 用脚本返回的页面列表作为引用扫描结果
   • 逐页判断是“删除整页”还是“保留页面但移除该素材引用”

3. 安全确认：

   • 如果影响超过 5 个页面时，先把受影响页面完整列给用户，再做二次确认
   • 如果某个实体或主题只被这个素材引用，提示用户是否连同页面一起删除

4. 执行级联清理：

   • 删除 raw/ 下对应原始文件
   • 删除 wiki/sources/ 下对应素材摘要页
   • 对 wiki/entities/、wiki/topics/、wiki/comparisons/、wiki/synthesis/ 中仍需保留的页面，只移除该素材相关的引用段落
   • 更新 index.md
   • 在 log.md 追加删除记录
   • 标记 wiki/overview.md 需要重新生成

5. 清理缓存：

   • 删除完成后，对对应 raw 文件运行：

     bash ${SKILL_DIR}/scripts/cache.sh invalidate "<raw 文件路径>"
     

6. 断链检查：

   • 用 grep 或 delete-helper.sh 再扫一遍指向已删除页面的链接
   • 清理明确可判定的断链；如果归属不清，保留原文并提示用户后续人工确认

7. 向用户报告结果：

   zh：

   已删除：
     - raw/articles/2024-01-15-ai-article.md
     - wiki/sources/2024-01-15-ai-article.md
   已更新（移除引用）：
     - wiki/entities/AI-Agent.md
     - wiki/topics/大语言模型.md
   需要重新生成：
     - wiki/overview.md
   

   （英文版按「输出语言规则」生成，结构相同。）

---

工作流 10：crystallize（结晶化）

触发条件： 用户说"结晶化"、"crystallize"、"把这个记进知识库"、"这段对话很有价值"

输入： 用户主动提供的内容（文字粘贴进对话，或明确引用某段上下文）。 用户必须主动提供内容，Claude 不自动提取当前会话。

处理步骤（MVP）：

1. 用户提供内容（文字粘贴进对话）
2. Claude 从内容中提取：
   • 核心洞见（3-5 条）
   • 关键决策和原因
   • 值得记录的结论
3. 生成 wiki/synthesis/sessions/{主题}-{日期}.md，格式参考 templates/synthesis-template.md
   • 本轮不要求 crystallize 页面补 sources，默认不参与 graph source overlap
4. 更新 log.md（记录本次结晶化操作）

MVP 版本不自动创建 entity 页面，不自动更新 index.md。

confidence 规则： 结晶化来源的内容默认标记为 INFERRED（来自推断/对话，非原始文档）。

输出示例： 已创建 wiki/synthesis/sessions/AI-agent-设计决策-20260413.md 已更新 log.md