llm-wiki

LLM Wiki

プレーンな Markdown によるナレッジベースです。ソースは raw/ に保存され（不変）、そこから自分で管理する wiki/ の記事を作成します。YAML フロントマター付きのローカル Markdown で、GitHub で読みやすく、Obsidian の保管庫として開くこともできます。サーバーもデータベースも埋め込みも必要ありません。

基本理念（Karpathy）：LLM が wiki を作成・維持し、人間がソースを選び、質問します。知識は取り込み時に一度だけコンパイルされます。

呼び出し

デフォルトはクエリです。 Ingest、Lint、Audit、Critique は意図的に行う 4 つの操作で、それぞれの動詞を指定するか、明確にその操作を求めるリクエストがあった場合にのみ実行します。それ以外はすべて wiki に対するクエリです。単なる質問、「X について何を知っていますか」、「Y に関する情報をすべて要約して」などが該当します。query キーワードは不要です。

先頭のモード引数で、該当する操作に直接振り分けます。

• ingest（別名 add）- 後続のテキストをソースとして扱います。URL、パス、または貼り付けられたコンテンツが該当します。
• lint - ヘルスチェックを行います。追加の入力は不要です。
• audit - 後続のテキストで、検証する記事またはトピックを指定します。
• critique（別名 scrutinise）- 後続のテキストで、調査する記事、トピック、または貼り付けられたコンテンツを指定します。
• query（別名 ask）- 質問が別の操作のようにも見える場合に、クエリとして処理するよう強制します。

それ以外の場合、自然言語のリクエストが Ingest、Lint、Audit、Critique のいずれかを明確に求めている場合に限り、その操作に振り分けます。それ以外はすべてクエリとして回答します。

常に必須のルールと、状況に応じたルール

すべての操作で、常に次のルールに従います。

• ユーザーのリクエストに対してのみ操作し、バックグラウンドで書き込みを行わないでください。
• 書き込みを伴うコンパイルは、すでに raw/ にあるソースからのみ行います。ライブ URL や外部パスから直接コンパイルしないでください。
• 書き込みを行った場合は、wiki/index.md を更新し、wiki/log.md に追記します。
• 記事の内容が変更された場合は、updated を更新します。
• 古くなった知識は、削除したりその場で編集したりせず、新しい内容で置き換えます。

その他のルールは状況に応じて適用されます。以下の分岐からタスクに該当するものを選び、操作する前にそのファイルを読んでください。参照先の指定はファイルを開く指示であり、引用を意味するものではありません。判断に迷った場合は、ファイルを読んでください。推測して wiki を破損させるより、そのほうが簡単です。

• ソースを取り込む場合 -> references/ingest.md
• まだ wiki/ がなく、この取り込みで初期化する場合 -> references/init.md
• 新しい wiki の目的を決める場合、または llm-wiki が目的に適しているか判断する場合 -> references/scoping.md
• ソースが PDF、Word ファイル、スライド、画像、またはスプレッドシートの場合 -> references/rich-format-ingest.md
• ソース全体ではなく、重要な内容だけを抽出したい場合 -> references/distilled-ingest.md
• ソースが文字起こし、チャットログ、インタビューメモ、またはノイズの多い長文記事の場合 -> references/high-fidelity-ingest.md
• 一度に多数のソースを扱う場合、または一度の処理でコンテキストを使い切ってしまう場合 -> references/bulk-ingest.md
• wiki の対象がコードベースの場合 -> references/codebase-wiki.md
• mermaid の概念マップを作成または維持する場合 -> references/concept-map.md
• 知識のギャップを記録または解消する場合 -> references/gaps.md
• local/ 内の個人的な未コミットコンテンツを扱う場合 -> references/local-content.md
• 作業ディレクトリ内に複数の wiki が並存している場合 -> references/multiple-wikis.md
• 回答をアーカイブページとして wiki に保存する場合 -> references/archive.md
• 古い形式の wiki を扱う場合、または type、インデックス形式、ログ形式について質問する場合 -> references/okf.md
• 読み取り専用の視点として wiki 全体に graphify を実行する場合 -> references/graphify.md

Lint、Audit、Critique では、それぞれのセクションに記載された専用の参照先を適用します。

設計思想

以下のセクションで扱っていない内容については、次の方針に従います。

• 保持時ではなく、取り込み時にフィルタリングします。 何を残す価値があるかを判断し、ソースが到着した時点でシークレットを取り除きます。
• 減衰ではなく、置き換えを行います。 ナレッジはタイマーで期限切れになりません。新しい情報が古い情報に取って代わる場合は、古い記事に「古くなった」と記し、置き換え先を示したうえで、そのまま保持します。置き換えられた決定も、現在の状態を説明する根拠になります。
• 確信度スコアではなく、証拠を示します。 主張に 0.85 のような数値を付けてはいけません。どのソースが裏付けているか、どのソースが矛盾しているか、最後に確認されたのはいつかを記します。
• 監査証跡には Git を使います。 履歴とロールバックは、独自のバージョン管理用フィールドではなく、バージョン管理から得ます。git リポジトリの使用を推奨します。
• 呼び出しを起点とし、人間が介在します。 ユーザーから依頼されたときに動作します。バックグラウンドの自動処理が、監督なしで Wiki に書き込むことはありません。ユーザーが内容を管理し、あなたが記録作業を担います。
• テキストのみで完結します。 プレーンな Markdown、相対リンク、YAML フロントマターを使います。一般的なツール（grep、git、エージェントのファイルツールやウェブツール）は使用できます。外部サーバー、ベクトルストア、埋め込みパイプライン、ナレッジグラフデータベース、マルチエージェントの同期レイヤーやガバナンスレイヤーは不要です。インデックスと grep で、個人用 Wiki の規模には十分対応できます。

アーキテクチャ

ユーザーのプロジェクトルートの下に配置します。

raw/ - ソース資料。信頼できる唯一の情報源です。「不変」とは、取り込み後に編集しないことを意味し、フィルタリングされていない元の資料である必要はありません。raw/ のファイルは、逐語コピーか、冗長なソースを確認して要点をまとめた抽出物（fidelity: distilled、references/distilled-ingest.md）のいずれかです（後者を推奨）。いったん書き込んだら、読み取り専用とし、変更してはいけません。トピック別のサブディレクトリを作成します。例：raw/machine-learning/。

wiki/ - 自分で作成する記事です。トピック別のサブディレクトリは1階層のみとします：wiki/<topic>/<article>.md。特別なファイルは4つあります。

• wiki/README.md - このスキルを知らずに Wiki を開いた人向けの案内です。主に静的な内容で、初期化時に作成します。
• wiki/index.md - OKF インデックス形式のグローバルカタログです。トピックごとのセクションに * [Title](path) - summary を記載し、Updated 列は設けません。クエリの入り口となります。
• wiki/log.md - grep 可能なプレフィックスを付けた追記専用の操作ログです。
• wiki/gaps.md - 既知の未解決事項を記録します。参照されているものの未記述の概念や、Wiki では答えられない質問を記載します。

local/（任意） - git の対象外にする個人用 Markdown です。下書き、作業メモ、非公開のソースを保存します。raw/ や wiki/ と同じ階層に置き、Wiki の .gitignore で除外します。インデックス、ログ、ギャップ、カスケード、監査の対象外です。ルールは1つです。local/ から wiki/ と raw/ へのリンクは許可されますが、コミットされるファイルから local/ へのリンクは一切作成してはいけません（他のクローンではリンク切れになり、パスが git に漏れるためです）。すべてのルールと昇格の手順については references/local-content.md を参照してください。

SKILL.md（このファイル）- スキーマレイヤーです。テンプレートは references/ にあります。

ファイル形式

すべての記事と raw ファイルは、YAML フロントマターに続いて標準的な Markdown で構成されます。フロントマターは機械可読形式（Obsidian Properties、Dataview クエリ）です。本文のリンクは GitHub と Obsidian のグラフおよびバックリンクに表示されます。

記事のフロントマター：

---
title: Transformer Architectures
type: concept          # concept | entity | archive
topic: machine-learning
resource:              # optional canonical URI of the asset an entity describes
created: 2026-04-03
updated: 2026-04-03
status: current        # current | stale
superseded_by:         # relative path to replacement, set only when status: stale
tags: [transformers, attention]
aliases: []
---

• updated は「ナレッジが最後に変更された日付」の正式な値で、Lint で読み取られます。ファイルに変更を加えたときではなく、内容が変更されたときに更新します。インデックスには記載しません（OKF ではフロントマターで最新性を管理します）。
• type: archive は、結晶化したクエリの回答（references/archive.md）を示します。アーカイブは特定の時点のものであり、連鎖的に更新されることはありません。
• resource は、entity 記事が説明するアセット（テーブル、サービス、API、リポジトリ）の正式な URI で、本文の Sources/Raw の出典情報とは異なります。任意項目で、抽象的な concept 記事にはありません。OKF の resource フィールドに対応します（references/okf.md）。
• status と superseded_by は、旧情報への置き換えを管理します（Ingest > Conflicts and supersession を参照）。現行の記事では superseded_by を空のままにしてください。
• tags と aliases は任意項目で、Obsidian と Dataview 用です。

この wiki は Open Knowledge Format（OKF）v0.1 バンドルのスーパーセットであるため、エクスポートなしで OKF ツールから読み取れます。旧形式の wiki に対して Lint または Ingest の途中で作業する場合、type フィールドを作成または移行する場合、あるいはインデックスやログの形式について質問がある場合は、必ず references/okf.md を読み、その指示に従ってください。

リンクとパス

wiki/ 内のファイルでは、すべてのリンクは現在のファイルからの相対パスです。

• 同じトピック：Other Article
• 別のトピック：Other Article
• Raw ファイル：Source（プロジェクトルートまでは 2 階層）

会話の出力では、wiki/topic/article.md のようにプロジェクトルートからの相対パスを使用してください。superseded_by には、本文のリンクと同じファイル相対形式を使用します。

特別なファイル

wiki/README.md では、このスキルを持たない読者向けに、raw/wiki の分割、フロントマターのフィールド、削除ではなく旧情報への置き換えを行うこと、そして index.md、log.md、gaps.md の役割を説明します。概要レベルの静的な内容にとどめ、ここに記載された手順を複製するのではなく、このファイルの手順を参照するようにしてください。テンプレート：references/templates/wiki-readme-template.md。

wiki/index.md は、あらゆるクエリでエージェントが最初に読むファイルです。手動で管理し、Dataview で一部を生成できる場合でも正式なものとして扱います。

wiki/log.md は追記専用で、時系列順に記録します。正式な記録は git の履歴に残ります。OKF の更新ログ形式：

• 新しい日付が先になるように ## YYYY-MM-DD 形式の日付見出しを付けます。grep "^## " wiki/log.md | head で最近の日付を確認できます。
• 見出しの下に操作ごとに 1 つの箇条書きを置き、太字の操作名で始めます：**Ingest**、**Query**、**Lint**、**Audit**、**Critique**、さらに **Supersession**。
• 今日の日付の見出しの下に追記します。見出しがない場合は、ファイルの先頭に作成します。
• 箇条書きは簡潔にします。変更した記事へのリンクを記載し、変更内容は記事本文と git diff に記録します。

wiki/gaps.md は、既知の不明点を次の 2 種類のエントリーで登録します。

• wanted - 記事から参照されているものの、該当ページがない概念。
• question - ソースで提起された、またはユーザーから尋ねられたものの、wiki では回答できない質問。

エントリーはトピックごとにまとめ、需要の証拠（そのギャップを参照する記事の数、質問された頻度）に基づいて順位付けします。スコアによる順位付けはしません。Ingest、Query、Lint の際に記録し、バックグラウンドプロセスでは記録しません。削除ではなく、解決先へのリンクによってクローズします。grep で検索できます：grep "^### \[open\]" wiki/gaps.md。形式、記録ルール、ライフサイクルの詳細：references/gaps.md。

初期化

初期化は、wiki/ のないディレクトリに初めて取り込むときにのみ行われます。何かを作成する前に、必ず references/init.md を読み、その手順に従ってください。 まずスコープを定める手順（references/scoping.md）から始まります。llm-wiki は、個人での利用なら期間を問わず、チームでの利用ならプロジェクトや取り組みの範囲に適しています。ただし、複数の製品にまたがる長期保存先や、社外の関係者が検索することを想定したものには適していません。ファイルを書き込む前にスコープを確定してください。スコープは以降のすべての操作を規定します。

Query または Lint で wiki の構造が見つからない場合は、wiki のサブディレクトリが複数あるか確認してください。それぞれに wiki/ と raw/ がある場合は、未初期化の wiki ではなく、複数の独立した llm-wiki を並べて運用する構成です。どちらも存在しない場合に限り、ユーザーに「wiki を初期化するには、まず取り込みを実行してください。」と伝えてください。自動作成はしないでください。複数の wiki をまたいで検索または保守する前に、references/multiple-wikis.md を読んでください。

---

取り込み

ソースを raw/ に取り込んでから wiki/ にまとめます。必ず両方の手順を実行してください。

取り込む前に、必ず references/ingest.md を読み、その手順に従ってください。

ソースをどの程度残すか決める

取得前に決めてください。raw/ に何を保存するかが決まります。

• 逐語（デフォルト） - 監査で照合するための、改変されない正確なコピーです。ユーザーから別の指示がない限り、これを使用してください。
• 要点抽出 - 重要度の高い内容だけを残し、余分な部分を取り除きます。ユーザーが「価値のある内容」「重要度の高い部分」「役立つ箇所だけ」「要点だけ」「重要なポイント」「重要なこと」などを求めた場合に選択してください。具体的な内容を一般化して消すのではなく、余分な部分を_取り除く_方法で要点を抽出する references/distilled-ingest.md に従ってください。また、重要な内容が失われていないことを確認する、必須の別サブエージェントによるレビューで締めくくってください。

ソースごとにモードを1つ選びます。形式が豊富（docx の書き起こし、PDF など）であることは、モードの判断材料にはなりません。まず Markdown に変換してから、選んだモードに応じて残すか要点を抽出してください。

長く情報密度の低いソースは要点抽出を提案してください。デフォルトで逐語的に丸ごと取り込んではいけません。 ソースが長く情報密度が低い場合（会議の書き起こし、チャットのエクスポート、インタビューのメモ、長大なスレッドなど）で、モードが指定されていなければ、raw/ に書き込む前に選択肢を提示してください。要点抽出の方法も説明します。重要な情報を残し、意図、意味、役立つ可能性のある文脈はすべて保持しつつ、要約と重複の削除を行い、原文に忠実であり続けます。同時に、破棄した原文を監査で照合できなくなるという代償も伝え、そのうえでユーザーに選んでもらってください。

コンパイルは raw/ のみを参照してください。 すべてのソースは、コンパイル前に Markdown 形式で raw/ に保存してください。ライブ URL や外部パスから直接コンパイルしてはいけません（テンポラリファイルは消失し、URL は変更される可能性があり、Raw リンクは維持する必要があります）。すでに raw/ にある Markdown ファイルは、そのままコンパイルできます。

コンパイル時の判断

説得を目的とする情報源。 意見記事、ベンダーの主張、戦略メモなど、報告ではなく主張を展開する情報源を確定した知識としてコンパイルする前に、批評パス（references/critical-analysis.md）を検討してください。推論上のリスクを報告し、判断はユーザーに委ねます。多くの場合、結論は異論のある主張を情報源に帰属させるか、その疑問を gaps.md に記録することになります。

長文およびノイズの多い情報源。 文字起こし、チャットログ、長い記事、インタビューのメモには、コンパイルを一度行うだけでは気づかないうちに抜け落ちてしまう詳細が含まれています。references/high-fidelity-ingest.md に従ってください。まず持続的に参照される項目（決定事項、主張、数値、固有名詞、未解決の疑問）を列挙し、そのリストから記事を書いた後、記事と照合しながら情報源をもう一度読み直します。情報源の正確な用語、数値、断定の度合いを保ち、重要な主張にはインライン引用と位置情報（セクション、ページ、タイムスタンプ）を付け、そのそばに元のリンクを配置します。主張が1つだけの短い情報源には、通常のコンパイルで十分です。

概念マップ（任意）。 複数の記事が、分岐、収束、置き換え、因果関係の連鎖など、文章ではうまく表現しにくい形で関連している場合、小規模な mermaid 図が役立つことがあります（references/concept-map.md）。current 記事のマップは重要な役割を担います。map-sources マーカーを付け、カスケード更新の際に維持します。type: archive ページのマップは、日付入りのスナップショットです。

矛盾と置き換え

新しい情報源が既存の内容と矛盾していないか確認します。

• 見解が食い違い、どちらにも妥当性がある → 証拠のつながりを示し、双方の主張をそれぞれの情報源に帰属させて、矛盾をインラインで注記します。「キャッシュには Redis を使用しています（情報源 A、情報源 B）。一方、情報源 C は Memcached を報告しています。」数字で勝者を決めてはいけません。矛盾する主張が別々の記事にある場合は、両方の記事に記し、相互にリンクします。

• 新しい情報源が古い知識を明確に置き換える → 削除せず、置き換えとして扱います。古い記事で status: stale を設定し、superseded_by: に置き換え先のパスを指定して、タイトルの直下にコールアウトを追加します。

  > [!warning] Superseded by [New Article](new-article.md) (2026-04-03). Kept for history.
  

  置き換え先の記事を通常の current 記事として作成または更新し、本文で何を置き換えるのかに触れます。その他の内容は Git の履歴に残ります。

大量取り込みと並列取り込み

一度に多数の情報源を扱う場合、または1回の処理でコンテキストを使い切ってしまう場合は、抽出を並列化し、コンパイルは逐次処理にしてください。完全な手順と取り込み提案のスキーマについては、references/bulk-ingest.md を参照してください。

以下のルールに従うことで、並列バッチによる Wiki の破損を防ぎます。

• 並列展開の前にトピックを割り当てます。 既存の raw/ と wiki/ のトピックを確認し、バッチのトピックセットを確定してから、各サブエージェントに渡します。これにより、異なる名前を独自に作られることを防ぎます。
• サブエージェントは抽出を行い、コンパイルは行いません。 各サブエージェントは raw/<assigned-topic>/ の下にのみ書き込み、構造化された提案を返します。wiki/、index.md、log.md には触れません。
• wiki/、index.md、log.md への書き込みはオーケストレーターのみが行います。 1つの見通しのもとで提案を統合します。同じ概念に関する提案を共通の証拠のつながりを持つ1つの記事にまとめ、情報源の日付順に適用して置き換えが新しい順に解決されるようにし、その後、カスケード処理を行ってインデックスとログを一度だけ更新します。
• コミット前にチェックポイントを設けます。 作成、統合、置き換え、明らかになった矛盾をまとめた概要を提示し、バッチの git commit を行う前にユーザーの返答を待ちます。根拠のしっかりした記事が10本あれば、内容の薄い記事50本より優れています。

---

クエリ

Wiki を検索して質問に答えます。トリガー：「X について何を知っていますか？」「Y についての内容をすべて要約して」「A と B を比較して」。

手順

1. 関連記事を探すために wiki/index.md を読みます。
2. それらの記事を読みます。インデックスにない関連ページは、本文中のリンクとバックリンクをたどります。リンク元のページを一覧するには grep -rl "article-name.md" wiki/ を実行します。
3. 回答をまとめます。トレーニングで得た知識よりも wiki の内容を優先します。Markdown リンク [記事タイトル](wiki/topic/article.md)（プロジェクトルートからの相対パス）で引用します。
4. 引用した記事の status: stale を記載し、後継記事を示します。
5. local/ がある場合はそこも検索し、各該当箇所に local/ (uncommitted) とラベルを付けて、共有ナレッジと誤認されないようにします（references/local-content.md）。クエリは 1 つの wiki に対して実行します。ユーザーの別の wiki を黙って混ぜてはいけません。質問が複数の wiki にまたがる場合は、その旨を伝え、どの wiki を参照するか尋ねます（references/multiple-wikis.md）。
6. 会話内で回答します。依頼されない限り、ファイルは書き込みません。
7. 未回答を記録します。 wiki で回答できなかった場合、または一部しか回答できず、質問が wiki の対象範囲内にある場合は、wiki/gaps.md に記録することを提案します。該当するギャップの需要証拠に今日の日付を追記するか、新しい question エントリーを追加します。記録するのはユーザーの許可を得てからにしてください。通常のクエリでは何も書き込みません（references/gaps.md）。

ユーザーが wiki の内容ではなく、推論が妥当かどうかを尋ねた場合は、クリティーク（references/critical-analysis.md）に切り替えます。

体系化（アーカイブ）

ユーザーが回答を wiki に保存するよう求めた場合は、必ず references/archive.md を読み、その手順に従ってください。 回答は type: archive のページとなり、取り込んだ情報源のように知見を蓄積できます。

---

リント

ヘルスチェックは 2 段階で行います。決定論的な問題は自動修正し、判断が必要な問題は報告します。黙って書き換えることはありません。 自分の判断で記事本文を書き換えてはいけません。リントは内部整合性を確認します。記事を情報源と照合するには Audit を使います。

修正を行う前に、必ず references/lint.md を読み、その手順に従ってください。 各段階のチェック項目と修正動作がすべて記載されています。以下の箇条書きは対象範囲の索引であり、手順ではありません。

• 決定論的（自動修正）： インデックスの整合性、内部リンクと生リンク、フロントマター、「関連項目」、ログの保持、wiki スキルファイルのリンク、コンセプトマップの鮮度、ギャップ一覧、local/ の漏えい防止。確認なしで安全に修正できます。
• ヒューリスティック（報告のみ）： 事実の矛盾、後継記事があるのに stale とマークされていない記事、孤立ページ、相互参照の欠落、文書化されていない概念（wanted ギャップとして提案）、記事が回答済みの未解決ギャップ、複数の概念を扱う記事、内容が古くなったアーカイブ、価値の低いコンセプトマップ、宣言されたスコープや期間を超えて内容が変化したチーム wiki、ルート SKILL.md、CLAUDE.md、スコープブロック、wiki の .gitignore の欠落。これらは報告し、自動修正してはいけません。

決定論的な段階には、uv で実行する依存関係不要の読み取り専用ヘルパーが 2 つあります。構造上の問題（フロントマター、インデックス、リンク、生リンク、local/ の漏えい防止）は scripts/lint_wiki.py <project-root> で、コンセプトマップの妥当性は scripts/lint_mermaid.py で確認します。シェルスクリプトを独自に作るのではなく、これらを実行してください。uv がない場合は grep とファイルツールを使い、mermaid は目視で確認します。ヘルパーが問題を検出し、修正はあなたが行います。

リント後

wiki/log.md の今日の日付の見出しの下に記録します。

* **Lint**: <N> issues found, <M> auto-fixed.

監査

記事の主張を、記事が引用している raw/ ソースと照合して検証します。Lint は内部整合性をチェックしますが、Audit は外部との整合性をチェックします。つまり、引用元が記事の記述を実際に裏付けているかを確認します。オプトイン方式で、指定された記事またはトピックに対してユーザーが実行を指示した場合にのみ行われ、自動では実行されません。引用されているすべてのソースを全文読み込みます。実行指示の例：「Xを監査して」「Yの引用をチェックして」「wikiは今もソースと一致している？」

監査の前に、必ず references/audit.md を読んで、その指示に従ってください。対象の選定、主張の抽出、ソースごとのサブエージェント向けプロンプト、判定スキーマが記載されています。

• 報告のみとし、独断で記事の文章を書き換えてはいけません（Lint のヒューリスティック層と同じ制約です）。裏付けが取れなかった主張は、ユーザーが修正、差し替え、または受け入れられるように提示します。
• 引用元ごとに読み取り専用のサブエージェントを1つ割り当て、並列で処理した後、問題の深刻度が高いものから順にまとめます。

監査後

wiki/log.md の今日の日付の見出しの下に記録します。

* **Audit**: [<article or topic>](<path>) - <N> claims, <S> supported, <U> unsupported/partial.

ユーザーが監査結果の保存を求めた場合は、監査した記事を引用する type: archive ページとしてまとめます。references/archive.md を読んで、その指示に従ってください。

---

批評

ソースや記事の論理を検証し、論証の構成、隠れた前提、論理的誤り、バイアスのリスク、内部整合性について、妥当な点を報告します。Audit は引用されている raw/ ソースとの外部整合性をチェックしますが、Critique は論理自体の妥当性をチェックし、実証的な主張を現実世界の情報と照合して事実確認することはありません。Audit と同様に、オプトイン方式でユーザーが実行を指示した場合にのみ行い、読み取り専用で、文章を書き換えることはありません。ユーザーが指定した対象が raw/ のソース、wiki/ の記事、貼り付けられた内容のいずれであっても実行でき、raw/ は必要ありません。実行指示の例：「Xを批評して」「この論証は妥当？」「どんな前提が置かれている？」「Yの論理を検証して」。

批評の前に、必ず references/critical-analysis.md を読んで、その分析手順と出力形式に従ってください。記憶を頼りに作業してはいけません。 論理が妥当な場合は、その旨を明確に伝えてください。批判を捏造してはいけません。対象が複数ある場合は、対象ごとに読み取り専用のサブエージェントを1つ割り当て、並列で処理した後、妥当性の低いものからグループ化して提示します。

批評後

wiki/log.md の今日の日付の見出しの下に記録します。

* **Critique**: [<article, topic, or source>](<path>) - <overall assessment>.

Critique 自体は、それ以外のものを書き込みません。ユーザーの許可があれば、批評した対象を引用する type: archive ページとして分析をまとめられます。references/archive.md を読んで、その指示に従ってください。または、明らかになった前提や未解決の疑問を wiki/gaps.md の question ギャップとして記録できます（references/gaps.md）。

---

オプション：外部の視点として graphify を活用する

graphify スキルまたはツールを利用できる場合は、wiki を対象に、一時的かつ読み取り専用のナレッジグラフとして実行できます。記事間のつながりの把握、孤立した記事や不足している相互参照の発見、取り込み前の大規模な raw/ コーパスのトリアージ、または関連性の高い質問への回答に役立ちます。信頼できる情報源は引き続き Markdown です。graphify-out/ は生成される gitignore 対象のディレクトリであり、コミットしてはいけません。検出結果を反映する場合は、通常の llm-wiki 操作（See Also、gaps.md への記録、差し替え、Query の回答）を通じて行い、まず Markdown と照合して確認してください。graphify を使う場合は、最初に references/graphify.md を読んで、その指示に従ってください。

---

注意点

• Wiki 内のパスの方向。 wiki/<topic>/ から raw ファイルへは 2 階層上です（../../raw/<topic>/file.md）。同じトピックの記事はファイル名だけで指定します。../ の数を間違えることが、リンク切れの最も一般的な原因です。
• インデックスの接頭辞を記事に合わせてください。 記事が置き換えられたりアーカイブされたりしたら、同じ作業中にインデックスの概要にある [Stale]／[Archived] の接頭辞を設定または切り替え、主張が変わった場合は概要も更新してください。
• 長いソースでは、詳細がいつの間にか失われます。 トランスクリプトをそのまま文章にまとめると、主張や正確な数値が抜け落ちたり、曖昧になったりします。まず保持すべき要点を列挙し、仕上げる前にソースと記事を照合して読み直してください（references/high-fidelity-ingest.md）。
• raw/ にあるリッチ形式の原本だけを削除してください。 バイナリを Markdown に変換した後、原本を削除してよいのは、原本が raw/ 内（Markdown のみ）にあり、変換結果が忠実であることを確認済みの場合だけです。Downloads や一時ディレクトリにある PDF はユーザーのものです。Markdown 版を raw/ に作成し、原本には手を加えないでください。
• ギャップはウィッシュリストではなく、未開拓の領域です。 記事から参照されている、またはクエリで尋ねられたなど、根拠がある場合に限り wanted ページや未解決の question を記録し、解決リンクでギャップを解消してください。埋まったギャップをそのまま残さないでください（references/gaps.md）。
• コンセプトマップは気付かないうちに古くなります。 記事を変更すると文章は更新されても、マップには古い関係性が残ることがあります。連鎖的な更新の際に再確認し、map-sources マーカーを正確に保ち、価値を加えなくなったマップは削除してください（references/concept-map.md）。