wiki-manager

LLM Wiki Manager

LLM でコンパイルされたナレッジベースを管理します。ソースドキュメントは raw/ に取り込まれ、その後、相互にリンクされた Markdown 記事からなる Wiki に段階的にコンパイルされます。Claude Code がコンパイラーとクエリエンジンの両方を担います。Obsidian も外部ツールも必要ありません。

ハブのパス

解決方法：すべての操作の開始時に、まず ~/.config/llm-wiki/config.json を読み込んで HUB を解決します。hub_path を優先し、現在のマシン上で先頭の ~ のみを展開します（com~apple~CloudDocs 内のチルダは展開しません）。resolved_path はレガシーキャッシュとしてのみ扱い、hub_path がない場合、または展開後の hub_path を利用できず、resolved_path が初期化済みの場合に限り使用します。共有設定にマシン固有の resolved_path の値を書き込まないでください。設定ファイルがない場合は、フォールバックとして ~/wiki/_index.md を試します。stat／存在確認に成功しているにもかかわらず、wikis.json の読み込みや topics/ の一覧表示で Operation not permitted が発生する場合、ハブのパスは正しく、macOS がこのプロセスをブロックしています。エージェントを起動するアプリそのものにフルディスクアクセスまたは iCloud Drive へのアクセスを許可し、再起動するようユーザーに伝えてください。このエラーが発生した場合、~/wiki や resolved_path に切り替えないでください。完全な手順については、references/hub-resolution.md を参照してください。

設定ファイルは次のようになります。

{
  "hub_path": "~/Library/Mobile Documents/com~apple~CloudDocs/wiki"
}

設定がなく、~/wiki/ に _index.md がある場合は、それも使用できます。ただし、設定が先に確認されます。サンドボックス環境では ~/wiki/ にアクセスできないことがあります。以下に記載する ~/wiki/ への参照はすべて HUB を意味します。

Wiki の場所

デフォルトではトピック別のサブ Wiki を使用します。 HUB はハブであり、コンテンツは HUB/topics/<name>/ に保存されます。各トピックには、それぞれ独立したインデックス、ソース、記事が用意されます。これによりクエリを絞り込み、無関係なトピックが互いの検索対象に混入するのを防ぎます。

複数の分野にまたがって増えていくコレクション群には、memes-bitcoin、memes-ethereum、tools-bitcoin、examples-seedqr のような、種類を先に置くトピックスラッグを優先してください。調査対象の分野が主で、コレクションがそのトピック内の成果物の一つにすぎない場合は、対象を先に置くスラッグを使用します。

解決の優先順位：

1. --local フラグ → 現在のプロジェクト内の .wiki/
2. --wiki <name> フラグ → HUB/wikis.json に登録された名前付き Wiki。レジストリのパスは <HUB>、~、絶対パス、または HUB を基準とした相対パスとして解決し、レジストリのパスが古くなっている場合は HUB/topics/<name> にフォールバックします
3. 現在のディレクトリに .wiki/ がある → それを使用します
4. それ以外 → HUB（ハブ）を使用します

コマンドの対象がハブで、ハブにコンテンツがない場合は、代わりにトピック別のサブ Wiki を作成するよう提案してください。

完全なディレクトリ構成と、すべてのファイル形式の規約については、references/wiki-structure.md を参照してください。

基本原則

1. インデックスは派生キャッシュです。 .md ファイルとその YAML フロントマターが信頼できる唯一の情報源です。_index.md ファイルはキャッシュされたビューで、古くなっている場合は読み取り時に再構築されます。ナビゲーションでは常にまずインデックスを読み取ってください。ただし、信頼する前に、古くなっていないか確認してください（ファイル数と行数を比較）。派生インデックスプロトコルについては、references/indexing.md を参照してください。

2. 取り込んだデータは変更しません。 通常のワークフローでは、取り込んだソースを変更しません。明示的な撤回は、隠し入力の scripts/llm-wiki retract によって最初に実行されます。コンテンツ、アーカイブ、セッションがこれを拒否することはできません。

3. 記事は統合して作成し、コピーはしません。 Wiki 記事は複数のソースをもとに、文脈を加え、ほかの概念とつなげます。クリップボードではなく、教科書をイメージしてください。

4. Obsidian と Claude の両方に対応したリンクを付けます。 相互参照には、同じ行に [[wikilink]]（Obsidian のグラフビュー用）と標準の Markdown [text](path)（Claude のナビゲーション用）の両方を使います。形式は [[slug|Name]] ([Name](../category/slug.md)) です。適切な場合は双方向リンクにします。

5. フロントマターは構造化データです。 すべての .md ファイルには、タイトル、概要、タグ、日付を含む YAML フロントマターがあります。これにより、全文検索を行わずに Wiki を検索できます。

6. 一括処理より差分処理を優先します。 コンパイルでは、デフォルトで新しいソースのみを処理します。全体の再コンパイルはコストが高く、明示的に指定する必要があります（--full）。

7. 不足している情報は正直に伝えます。 質問への回答が Wiki にない場合は、その旨を伝えてください。決して幻覚で補わないでください。不足を補うために取り込むべき内容を提案してください。

8. 複数の Wiki を意識します。 問い合わせには、まずプライマリ Wiki の情報をもとに回答します。その後、関連する重複情報がないか、兄弟 Wiki のインデックスを（HUB/wikis.json 経由で）確認してください。関連性を示すことはできますが、Wiki 間でコンテンツを統合してはいけません。

9. 大きな書き込みは分割します。 1 回の Write 呼び出しで約 200 行を超えるファイルを作成してはいけません。大規模な生成中は API ストリームがアイドル状態になり、タイムアウトエラーが発生するためです。まず骨組み（フロントマター、見出し、最初のセクション）を書き、その後、順番に Edit 呼び出しを使って残りのセクションを追記してください。計画、記事、未加工のメモは、ツール呼び出し 1 回につき 1 セクションを書いてください。

10. アーカイブは目立たない形で保存します。 アーカイブされたトピック Wiki は HUB/topics/.archive/<slug>/ の下に置かれ、通常のセマンティックワークフローからは隠されます。 明示的なアーカイブ／lint 操作を通じて、構造上の保守を続けられます。 詳細な問い合わせでは、アーカイブされたインデックスの一致結果を別途提示する場合がありますが、ユーザーが明示的に含めない限り、アーカイブされたコンテンツを新たな統合に反映してはいけません。

11. セッションの記録は運用上のメモリーです。 ハーネスのセッションダイジェストは HUB/.sessions/ または .wiki/.sessions/ に置き、デフォルトではトピックの raw/ には置きません。 自動フックで編集済みのチェックポイントを記録する場合がありますが、トピック Wiki への昇格は明示的にユーザーが指示する必要があります。

12. フィードバックは候補となるメモリーです。 ユーザーからの訂正、好み、承認、計画受け入れのシグナルは、編集済みの候補として HUB/.sessions/feedback/ の下に記録する場合があります。ただし、一般的な応答は無視し、永続的な Wiki への昇格は明示的に行います。

13. プライベートアダプターは、コンテンツを扱わない外部実行プレーンです。 マシンローカルのレジストリはハブではなく、~/.config/llm-wiki/ の下に置きます。 アダプターのリポジトリにはツールコードのみを含めます。実際の入力とすべての実行時出力は、それぞれ別途管理される外部データプレーンに留めます。レビュー済みの wiki-safe 候補のみ、通常の来歴管理とコンパイルのワークフローを通じて Wiki に取り込めます。詳しくは references/adapters.md を参照してください。

14. スペシャリストは範囲の限られた手法であり、資格情報ではありません。 個人用の指示専用スペシャリストパッケージは HUB/.skills/ の下にローカルで保存し、アクティブなトピックごとに有効化します。読み込んでも、ツール、書き込みアクセス、専門家としての権限、エージェントを起動する許可が付与されることはありません。役立つ最小限の手法を選び、意見の相違を保ち、そのバージョン／ハッシュを記録してください。詳しくは references/specialists.md を参照してください。

15. プロジェクトのチェックポイントでは、包括的な網羅性とプライバシーシールが必要です。 詳しくは references/checkpoints.md を参照してください。

アダプタールーティング

アクションと URL が指定された場合は、「wiki」と明言されていなくても、取り込みや一般的なツールの案内をする前に adapter route --intent <effect> --resource <url> --json を実行します。一致した場合は、アダプターが管理するガイドを読みます。プロバイダーの手順はそのガイドに記載されています。URL だけでは書き込みの許可になりません。references/adapters.md を参照してください。

明示的な wiki skill-factory <request> は、登録済みの名前付きアダプターを選択します。URL ルートを作り出してはいけません。show/doctor を実行し、ガイドを読みます。これは自動では有効にならず、外部候補も無効のままです。インストール、トピックの有効化、コミット、公開は、それぞれ独立した操作です。

自動的な動作

明示的な /wiki:* コマンド以外でこのスキルが有効になった場合：

1. ハブのパスを解決し（上記の「ハブのパス」セクションを参照）、HUB/_index.md または .wiki/_index.md が存在するか確認します
2. マスター _index.md を読み、Wiki がユーザーの質問に関係しそうか判断します
3. 関連する内容がある場合 → 関連記事を読み、出典を引用して回答します
4. 関連する内容がない場合 → 通常どおり回答し、必要に応じて「これは /wiki:ingest で Wiki に追加できます」と提案します
5. 隣接する Wiki を確認する場合は、それぞれの _index.md だけを読みます。ユーザーから求められない限り、記事全体は読みません。既定ではアーカイブ済みの隣接 Wiki は対象外とし、詳細モードでは、アーカイブ済みのインデックスで一致した内容を別途報告できます。

起動、再開、または「前回の続き」に関する案内をする場合は、まずアクティブな Wiki の識別情報を <wiki-name> booted from <wiki-root-path> の形式で示します。config.md のタイトルを優先し、ローカルの .wiki/ プロジェクトでは親ディレクトリ名を、HUB/topics/<slug>/ ではスラッグを代わりに使用します。再開する作業がなくても、この行を含めます。

ユーザーが Wiki の成果物を信頼できるか尋ねた場合、監査を依頼した場合、出所や差分に言及した場合、または通常の質問応答を超える内容の検証を求めた場合は、通常の質疑応答として扱わず、監査ワークフローを使用します。

ワークフロー

取り込み

references/ingestion.md を参照してください。 流れ：ソース（URL／ファイル／テキスト／ツイート／受信箱）→ 取得／読み込み → メタデータの抽出 → raw/{type}/ への書き込み → インデックスの更新 → 未コンパイルの項目が多い場合はコンパイルを提案します。

コレクションの取り込み

references/ingestion.md § コレクションの取り込みを参照してください。 流れ：構造化された上流コレクション（Git リポジトリ、BIP 形式の提案セット、MediaWiki ダンプ／API）→ 上流アイテムの一覧作成 → raw/repos/ のマニフェストと変更不可の子ソースを作成 → raw インデックスの再構築 → 必要に応じて統合クラスタをコンパイルします。大量のインポートには /wiki:ingest-collection を使用し、HTML を再帰的にクロールしてはいけません。

プライベートアダプター

references/adapters.md を参照してください。 流れ：既存のローカルアダプターのチェックアウトを明示的に登録 → 読み取りルートと書き込みルートを宣言 → マニフェストのハッシュと describe ハンドシェイクを検証 → 同梱の決定論的 CLI を通じて v1 JSON リクエストを実行 → 成果物のパスとハッシュを検証 → すべての出力を外部に保持 → 必要に応じて wiki-safe 候補のみを確認し、通常の Wiki 書き込みを通じて有用な証拠を最小限だけ昇格させます。ガイドにエージェントが起動する対話型認可ヘルパーがある場合は、自分で起動し、長いターミナルコマンドやプロバイダーの URL ではなく、短いローカル引き継ぎリンクだけを提示します。アダプターのクローン、インストール、更新、公開、自動昇格は決して行いません。

個人用スペシャリストスキル

references/specialists.md を参照してください。 流れ：ユーザーが所有する、指示のみを記述した SKILL.md メソッドを HUB/.skills/ に維持 → 構造と安全性の境界を検証 → アクティブなトピックごとに安定した名前を明示的に有効化 → タスクの特徴に基づいて 0～3 個（通常は 1 個）を選択 → 選択したメソッドに同じ範囲限定の証拠パケットを渡す → 証拠の強さに基づいて検証し統合 → 名前、バージョン、コンテンツハッシュを記録します。インデックスを優先する候補スキャンには /wiki:specialist suggest を、範囲を限定したレビューには /wiki:specialist apply を使用します。CFO、医師、MBA、PhD などの肩書きを、資格や能力の向上と見なしてはいけません。

インベントリ

references/inventory.mdを参照してください。 フロー：インベントリへの適合性を確認 → アイテム、アイデア、取り込み候補、エンティティ、コーパス、質問、タスク、監視対象など、Wiki に関連する長期的な情報をinventory/配下のMarkdownレコードとして管理 → インデックスやフロントマターからリストのリクエストに答え、簡潔なチャット用テーブルまたは箇条書きとして提示 → 必要に応じて、派生ビューをinventory/views/配下に保存 → 明示的にドライランを先に実行する移行によって、従来のキュー形式の出力を変換できます。インベントリの移行は追加方式で行い、人間の確認を必須とします。インベントリには小さすぎるもの、大きすぎてデータセット／コレクションにすべきもの、Wikiの対象外のものについては、明確に伝えてください。

アイデア

references/ideas.mdを参照してください。 フロー：inventory/ideas/に記録 → 調査して具体化 → 承認を必須とする → BRIEF.mdを確定して昇格します。アイデアは系譜を維持し、プロジェクトはデリバリーを担います。

ポートフォリオ

references/portfolio.mdを参照してください。 フロー：アクティブなアイデアのインデックスと、プロジェクトのWHY.mdファイルを読む → 明示された系譜のみを相互リンクする → レコードをコピーせず、読み取り専用のテーブルを個別に生成します。

収集

references/inventory.mdおよび references/research-infrastructure.mdを参照してください。 フロー：範囲を限定したカタログのリクエストを設定 → 規模とメディアの扱いを推定 → 候補となる成果物、例、リソース、エンティティ、ツール、メディア、ミームを検索 → 有望なコンテキストページのみ取得 → エイリアス／再投稿／再ホストを重複排除 → found_in_contextの出典情報とメディアのメタデータを記録 → output/collect-<slug>-YYYY-MM-DD.mdにtype: collectionの出力を保存 → リストが十分に小さく長期的に有用な場合はインベントリレコードを、または中規模／大規模の場合はコーパスレコードを必要に応じて作成します。収集出力は、raw/、wiki/、inventory、またはdatasetsへの昇格前のステージング層としてLLMに役立ちますが、事実に関する主張の根拠となる未加工のソースの代わりにはなりません。メディアを含むコレクションでは、範囲を限定した公開バイナリメディアをデフォルトでダウンロードしてハッシュ化し、output/assets/collect-<slug>/に保存します。バイナリをraw/に保存してはいけません。また、タイムアウト、ファイルサイズの上限、Content-Typeの確認、メディアホストがIPv6で応答しない場合のIPv4再試行（curl -4）など、防御的なダウンロード設定を使用してください。明示された戦略と制限を超えて、「すべて」が網羅的な収集を意味するかのように扱ってはいけません。

データセットレジストリ

references/datasets.mdを参照してください。 フロー：大規模または外部のデータセットはWikiの外に置き、datasets/<slug>/MANIFEST.mdを通じてインデックス化 → 保存場所、スキーマの注記、小規模なサンプル、プロファイル、クエリのレシピを記録 → datasets/_index.mdとマニフェストのフロントマターのみからリストのリクエストに回答 → 明示的にドライランを先に実行する移行によって、従来のデータセット出力を必要に応じて変換できます。データセットの移行は追加方式で行い、元のデータをWikiにコピーすることは決してありません。

アーカイブ

references/archive.mdを参照してください。 フロー：トピックWiki全体をHUB/topics/<slug>/から HUB/topics/.archive/<slug>/に移動 → wikis.jsonのstatus: archivedを設定 → 通常のクエリ／コンパイル／調査／収集／出力／メンテナンスのコンテキストから非表示にする → フォルダーを元に戻し、status: activeを設定して復元します。v1では、個々の未加工ソースやコンパイル済み記事をアーカイブしてはいけません。

コンパイル

references/compilation.mdを参照してください。 フロー：未コンパイルのソースを調査 → 記事を計画 → 分類（概念／トピック／リファレンス） → 相互参照を加えて記事を作成／更新 → すべてのインデックスを更新します。

クエリ

フロー：_index.mdを読み込む → 要約／タグから関連する記事を特定する → 記事を読む → 関連項目のリンクをたどる → 追加の一致をGrepで検索する → 引用付きで回答をまとめる → 不足点を記録する → アクティブな関連ウィキを確認する。--resumeを指定すると、セッションファイル、最近のログエントリ、ウィキの統計情報、最終更新された記事を読み込んで「前回の続きから再開する」ためのブリーフィングを作成し、セッション中断後にコンテキストを再読み込みできます。詳細なクエリでは、独立した「アーカイブの一致」セクションでアーカイブ済みの関連ウィキのインデックスを確認する場合があります。アーカイブ済みの記事をすべて読むには、ユーザーの明示的な意図が必要です。

リント

references/linting.mdを参照してください。 フロー：構造を確認する → インデックスを確認する → リンクを確認する → コンテンツを確認する → 網羅性を確認する → レポートする → 必要に応じて自動修正する。デフォルトのリントでは、アクティブなコンテンツの健全性を保ち、アーカイブ済みのトピックはスキップしたものとして報告します。アーカイブ済みコンテンツの構造を明示的に保守するには、--include-archivedまたは--archived-onlyを使用します。

ライブラリアン

references/librarian.mdを参照してください。 フロー：アクティブなトピックのコンパイル済みwiki/レイヤーをスキャンする → 古さ、品質、ソースチェーンの完全性、リンクの健全性を評価する → .librarian/scan-results.jsonと.librarian/REPORT.mdを書き込む → 優先順位を付けた次のアクションを提案する。任意の--passes conventions（または旧式のschema）を指定すると、トピックガイドの改善に向けた提案出力を書き込む場合があります。新しいトピックウィキではトピックガイドがデフォルトです。古いウィキにもllm-wiki schema adoptまたはllm-wiki lint --fixで導入できます。ユーザーが明示的に承認しない限り、ライブラリアンはschema.mdを書き換えてはいけません。 ライブラリアンは記事の健全性を評価するアドバイザーです。リントによる構造チェックや、監査によるより広範な信頼性レビューに代わるものではありません。

監査

references/audit.mdを参照してください。 フロー：ライブラリアンの処理を実行するか再利用する → output/、wiki/、raw/にまたがる成果物の依存関係を調べる → 新しいソースの確認と対象を絞った調査を行い、信頼性に関する判定が収束するまで詳しく調べる → .audit/REPORT.mdを書き込む。

検索

フロー：インデックスをスキャンして要約／タグの一致を探す → 全文をGrepで検索する → 結果を順位付けする → 提示する。

ワークフローをまたいだインベントリの把握

インベントリは、孤立した情報ではなく、第一級の運用状態です。他のワークフローでは、インベントリを事実を裏付ける証拠として扱うのではなく、その存在に気づく必要があります。

• 取り込みとコレクションの取り込み：ユーザーが取り込みの前に追跡したい場合、またはソースが大きすぎる／曖昧な場合は、インベントリレコードの作成を提案します。インベントリ候補を取り込んだ場合は、生成されたrawまたはコレクションのマニフェストをレコードからリンクします。
• データセット：次のアクション、優先度、受け入れ状況、またはコーパスの重要性をユーザーが気にかけている場合は、データセットのマニフェストをインベントリレコードにリンクします。
• コンパイルとクエリ：インベントリを使って不足点、候補、次のアクションを提示しますが、事実に関する主張にはraw／wikiソースを引用します。
• 収集：まずカタログを出力として書き込みます。そのうえで、小規模で長期的に維持されるリストに限り、項目ごとのインベントリレコードを作成します。中規模／大規模で変動しやすいコレクションや、メディアを多く含むコレクションには、コーパスレコードを1つ使用します。
• 調査、監査、ライブラリアン、更新、計画、出力：長期的なフォローアップ、古くなった項目、ソースのキュー、またはウォッチリストについて、インベントリレコードの作成を提案します。ただし、大量のバックログを作成する前にサンプルを提示します。

セッション

references/sessions.mdを参照してください。 フロー：session enableでオプトインする → ハーネスフックが編集済みイベントをHUB/.sessions/queue/に追記する → ツール使用回数、コンパクション、停止／セッション終了、または手動チェックポイントのタイミングで、セッション状態とMarkdownダイジェストを更新する → session rehydrateでコンパクトなコンテキストブロックを取得する → session promoteで要約済みダイジェストをトピックのraw/notes/ノートに明示的にコピーする。自動キャプチャは許可されていますが、自動プロモーションは許可されていません。

フィードバックのキュレーション

references/feedback.mdを参照してください。 フロー：信頼できるユーザープロンプトフックまたはfeedback captureで、重要度の高いユーザーの訂正、好み、承認、計画受け入れのやり取りを分類 → 編集済みの候補をHUB/.sessions/feedback/に追記 → feedback list/showで確認 → feedback promoteで選択した候補をトピックのraw/notes/に明示的に書き込みます。 手動で記録した場合を除き、一般的な応答は無視します。

出力

フロー：関連する記事を収集 → 成果物（要約／レポート／スライドなど）を生成 → output/に保存 → インデックスを更新します。

学んだ教訓（ll）

フロー：セッションからエラー→修正のパターン、訂正、発見事項をスキャン → 構造化された教訓を抽出 → type: lessons-learnedを指定してraw/notes/に書き込み → 必要に応じて関連する記事を更新 → 必要に応じてCLAUDE.mdのルールを提案します。

リンク：ファイルパスとURL

ターミナルのリンクは、2行目に折り返されると機能しなくなります。すべてのWiki操作に次のルールを適用します。

1. 絶対パスを完全な形で記述 — ~、HUB、およびすべての相対パス要素を展開します。相対パスはクリックできません。
2. URLにはMarkdownのリンク構文を使用 — [短いテキスト](url)を使用し、折り返されてリンク切れになる長いURLをそのまま記述しないでください。
3. リンクの前にインデントを入れない — インデントによってターミナルの幅が狭くなります。リンクは行頭から始め、単独の行に置いてください。
4. 1行につきリンクは1つ — 長いパスを文中に埋め込まないでください。別の行に分けます：

   Saved to:
   /Users/name/wiki/topics/my-topic/output/report-2026-04-08.md
   

例については、references/research-infrastructure.md § エージェントプロンプトテンプレートを参照してください。ingest、compile、collect、research、output、assessに適用されます。

アクティビティログ

すべてのWiki操作では、Wikiルートのlog.mdに追記します。形式：## [YYYY-MM-DD] operation | Description。完全な形式については、references/wiki-structure.mdを参照してください。--remove-from-logsを使用する、ユーザーが明示的に指示した取り消しの場合を除き、既存のログエントリを編集または削除しないでください。

信頼度の評価

Wiki記事のフロントマターには、confidenceフィールドとしてhigh、medium、lowのいずれかが含まれます。

• high：複数の査読済み情報源が一致しており、十分に確立された知識です
• medium：情報源が1つである場合、一部のみ一致している場合、または最近の知見がまだ再現されていない場合です
• low：逸話的な情報、査読を経ていない情報源が1つだけの場合、または情報源同士の見解が一致しない場合です

クエリに回答する際は、信頼度を明記してください。lintの実行時には、信頼度がlowの記事にレビューが必要であることを示してください。

コンパイルのリマインダー

raw/_index.mdの取り込み日と_index.mdに記載された最終コンパイル日を比較して、未コンパイルの情報源を追跡します。取り込み後に未コンパイルの情報源が5件以上ある場合は、次のように提案します：「未コンパイルの情報源がN件あります。/wiki:compileを実行して統合してください。」

構造ガーディアン

次のいずれかの条件に該当した場合、簡易的な構造チェックを自動実行します。

トリガー

• 書き込み操作の後（ingest、compile、collect、research、output、inventory、dataset、archive） — 書き込まれた内容を確認します
• スキルの起動時に、Wikiのlintが7日以上実施されていない場合（_index.mdの「最終lint」を確認）
• コンテンツが誤った場所に見つかった場合 — トピックのサブWikiではなくグローバルハブに記事がある場合
• ユーザーがWikiの問題に言及した場合 — 「Wikiが壊れている」「空」「見つからない」「間違っている」
• Wikiが存在しない場合（初回実行） — コマンド一覧を表示する代わりに、ガイド付きオンボーディングフローに切り替えます。トピックの選択 → init → 最初のアクションの提案までユーザーを案内します。commands/wiki.md § 「Wikiが存在しない場合」を参照してください。

クイック構造チェック（軽量でインライン実行。完全なリントではありません）

1. Hub の整合性：Hub（HUB）に含めるのは wikis.json、_index.md、log.md、topics/、および任意の .sessions/ と .skills/ のみです。.skills/は、指示のみのパッケージとアクティブトピックの許可リスト契約に照らして検証します。Hub の直下にraw/、wiki/、inventory/、datasets/、output/、inbox/、または config.md が存在する場合は、**警告しますが、削除しないでください**。これらには、古い Wiki レイアウトから引き継がれたユーザーデータが含まれている可能性があります。references/linting.md の C11/C12/C16/C17/C19 に従って、コンテンツを適切なトピック Wiki に移動するか、アーカイブレジストリの不整合を修復するか、inbox/.unknown/に隔離する/wiki:lint --fix` を提案します。

2. インデックスの鮮度：アクティブなトピック Wiki について、raw/、wiki/、inventory/、datasets/ の各サブディレクトリに実際にあるファイル数と、それぞれの _index.md の行を比較します。.librarian/ や .audit/ などのメンテナンス／レポート用領域は除外します。不一致がある場合は、フロントマターから該当するディレクトリのインデックスを再生成し、参照先のないエントリを削除して自動修正します。

3. 孤立ファイルの検出：Wiki ディレクトリに .md ファイルが存在するものの、いずれの _index.md にも記載されていないファイルがないか確認します。見つかった場合は、インデックスに追加します。

4. ディレクトリの欠落とレガシーメタデータ：トピック Wiki の基本サブディレクトリ（raw/articles/、raw/papers/、wiki/concepts/、wiki/references/、output/ など）が存在することを確認します。欠落している場合は、空の _index.md を含めて作成します。inventory/ と datasets/ は遅延作成の任意レイヤーとして扱います。すでに存在する場合はインデックスを修復しますが、現在のインベントリまたはデータセットのワークフローで必要とされていない限り、完全に欠落している任意のツリーは作成しません。古いコンパイル済み記事については、lint --fix によって、ファイルの場所や既存の本文／フロントマターから category、summary、日付、volatility を推定できます。また、一致が明確な場合は、曖昧な生ソース参照を正確な raw/...md パスに書き換えることができます。

5. wikis.json の同期：HUB/topics/ 内のすべてのトピックサブ Wiki が wikis.json に登録されていることを確認します。Hub が所有するトピックパスには、/Users/<name>/... のような絶対パスではなく、移植可能な相対パス（topics/<slug>）を使用します。ディレクトリが存在するのに登録されていない場合は、追加します。登録済みのパスが古くても HUB/topics/<name> が存在する場合は、パスを修復します。登録されているものの、一致するディレクトリが存在しない場合は、エントリを削除します。

   HUB/topics/.archive/ 内のアーカイブ済みトピックサブ Wiki は、 path: topics/.archive/<slug> および status: archived で登録します。デフォルトのアクティブステータス／クエリ／コンパイルには含めないでください。

6. ログの存在確認：アクティブな Wiki と Hub に log.md が存在することを確認します。欠落している場合は作成します。

動作

• 問題がなければ何も報告しない — すべてが正常な場合は、何も報告しません
• 軽微な問題は自動修正する — インデックスの欠落、Wiki の未登録、孤立ファイルを修正します。修正してログに記録します
• 構造上の問題は警告する — コンテンツの配置場所が誤っている、ディレクトリが欠落している、インデックスが古いなどの問題について、ユーザーに伝え、/wiki:lint --fix を提案します
• ユーザーの依頼を決して妨げない — チェックを実行し、可能な範囲で修正して問題を報告した後、ユーザーが実際に依頼した作業を続けます

並行処理

複数の Claude Code セッションで、同じ wiki を同時に安全に読み書きできます。ロックは不要です。

• インデックスは、ディスク上の実ファイルから生成されます。2 つのセッションが同時に記事を書き込んだ場合、次の読み込み時に、存在するファイルを基にインデックスが再構築されます。どちらの再構築結果も、同じ正しい状態に収束します。
• log.mdは追記専用で、小さなアトミック書き込みを行います。並行する追記は安全です。明示的なプライバシー情報の削除処理ではファイルをアトミックに書き換えますが、ほかの wiki への書き込みと同時に実行しないでください。
• 記事／ソースファイルは個別に書き込まれます。異なるファイルを 2 つのセッションが作成しても、競合は発生しません。同じファイルを 2 つのセッションが編集する可能性は低く、発生した場合は最終書き込み優先で処理されます（wiki では問題ありません。コンテンツは常に生ソースから再構築できます）。

派生インデックスプロトコルについては、references/indexing.mdを参照してください。

セッション管理

リサーチセッションレジストリ

--min-timeを指定したリサーチセッションまたは論文セッションがアクティブな場合、wiki のルートには.research-session.jsonまたは.thesis-session.jsonファイルが存在します。

永続的な来歴情報も wiki のルートに保存してください。

• .session-events.jsonl — 再生可能な履歴を記録する追記専用イベントログ
• .session-checkpoint.json — 再開時の説明と監査に使用する最新の簡潔な要約

セッションレジストリファイルは、一時的なクラッシュリカバリ状態です。イベントログとチェックポイントは、永続的な来歴の記録です。

Structural Guardian の動作：

• status: "in_progress"かつstart_timeが 7 日より前のセッションファイルが存在する場合 → 次の警告を表示します：「古いリサーチセッションが見つかりました。/wiki:researchでクリーンアップするか、手動で削除してください。」
• セッションファイルは一時的なものであり、構造ヘルスチェックやインデックス件数には含めません
• セッションファイルは git にコミットしないでください
• /wiki:auditで来歴をreplayableとして分類し、partialとならないよう、完了後も.session-events.jsonlと.session-checkpoint.jsonは通常保持してください

Harness セッションキャプチャ

自動化された Codex/Claude/OpenCode/Gemini セッションのキャプチャには、HUB/.sessions/（ローカル wiki の場合は.wiki/.sessions/）を使用します。これは、編集済みフックイベント、状態 JSON、派生インデックス、Markdown 形式のセッションダイジェストを保存する、非表示の運用レイヤーです。明示的に昇格されるまでは、トピックの根拠資料ではありません。

ストレージ構成、設定モード、フックアダプターの仕様、再構成時の動作、昇格ルールについては、references/sessions.mdを参照してください。