llm-wiki について
llm-wikiは、外部資料を蓄積するMarkdown Wikiを保守する提案段階のスキルです。記事や論文などを整理し、検索のたびに断片を探し直すのではなく、知識を積み重ねたい人を対象としています。
主な機能
- 01資料を相互リンク付きWikiページに取り込み
- 02質問への回答と再利用できる要約の保存
- 03古いページ、孤立ページ、矛盾の検査
- 04成熟したページを執筆コンテンツへ昇格
- 05階層に応じたレビューと書き込み制御
活用シーン
- 01記事や論文のメモをプロジェクトWikiに集約
- 02蓄積した資料をもとに頻出質問へ回答
- 03Wikiのリンク切れや古い記述を点検
- 04レビュー済みのWiki内容を執筆文書へ移行
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ boshu2/ agentops --skill llm-wikiインストール後、Claude Code で/llm-wikiを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/architecture.mdresearch.mdscripts/validate.sh詳細
LLM Wiki スキル(提案)
目的: LLM が管理する、外部知識(記事、論文、トランスクリプト、クリップしたウェブコンテンツ)の Markdown Wiki を継続的に蓄積し、記録管理の手間をなくしながら知識を蓄積します。2026 年 4 月に公開された Andrej Karpathy の「LLM Wiki」パターンに基づいています。設計の根拠と既存の AgentOps スキルとの連携方法については、references/architecture.md を参照してください。
ステータス: 提案 — まだマージされていません。評議会レビューのため、2026-04-11 に公開されました。このスキルの着想の元となった調査については、
.agents/research/2026-04-11-karpathy-llm-wiki-integration.mdを参照してください。
中核となるアイデアを一段落で
RAG には重大な欠点があります。知識が蓄積されないことです。クエリのたびに、元のソースコーパスから断片を再発見します。LLM Wiki パターンでは、クエリごとの RAG を、元のソースとユーザーの間に位置する、LLM が継続的に管理する永続的な Markdown Wiki に置き換えます。LLM は各元文書を一度読み、概念を抽出し、要約を書き、関連するアイデアを相互リンクし、全体を最新の状態に保ちます。クエリ時には、LLM はすでにまとめられた Wiki を読みます。はるかに高速で、情報が豊富で、知識が蓄積されていきます。
Karpathy のたとえ:「Obsidian は IDE。LLM はプログラマー。Wiki はコードベース。」 AgentOps の内部フライホイールパターンと同じものを、外部知識に適用しています。
このスキルに含まれるもの
Wiki 構造の保管庫に対する 4 つの操作の仕様です。
ingest— 新しい元ソースを処理 → Wiki ページを作成し、インデックスを更新して、ログに記録query— Wiki ページをもとに質問へ回答 → 統合結果を新しいページとして保管lint— 矛盾、古い主張、孤立ページ、欠落している概念を定期的にヘルスチェックpromote— 成熟した Wiki ページを下書きからレビュー済みに移行、または Wiki から執筆コンテンツに移行
このスキルに含まれないもの
compileの代替ではありません —skills/compileは AgentOps の内部アーティファクト(.agents/learnings/→.agents/compiled/)を扱います。llm-wikiは外部のソース資料(raw/→wiki/)を扱います。両者は相互補完的であり、対象は重複しません。違いについてはreferences/architecture.mdを参照してください。researchの代替ではありません —researchは調査から新たな研究アーティファクトを作成します。llm-wikiは既存の外部資料を整理します。研究アーティファクトから Wiki ページを引用でき、Wiki ページは研究アーティファクトの参考にできます。- RAG システムではありません — むしろ正反対です。RAG はクエリごとに断片を取得します。LLM Wiki はそれらを事前にコンパイルし、永続的なページにまとめます。
- 自動スケジュールはしません — このスキルが定義するのは操作であり、スケジュール設定(cron / systemd / launchd / Claude Code hooks)はホスト側の役割です。リファレンス文書では 3 層モデル(常時稼働の Tier 1 ローカル LLM、オンデマンドの Tier 2 Claude、人間による Tier 3)を説明していますが、特定のスケジューラーを強制するものではありません。
クイックスタート
# Initialize the wiki layout in the current project
/llm-wiki init
# Drop a raw file into raw/articles/ then ingest it
/llm-wiki ingest raw/articles/karpathy-llm-wiki-gist.md
# Query the wiki for what we know about a topic
/llm-wiki query "what's the Karpathy LLM Wiki pattern?"
# Lint the wiki for orphans, contradictions, stale pages
/llm-wiki lint
# Promote a mature wiki page out to authored content
/llm-wiki promote wiki/concepts/llm-wiki.md --to platform-lab/patterns/llm-wiki-architecture.md
フラグ
| フラグ | デフォルト | 説明 |
|---|---|---|
--tier 1|2|3 | 2 | オペレーターの階層。Tier 1 は status: draft のみを書き込み、執筆用ディレクトリには一切触れません。Tier 2 は status: reviewed を書き込み、昇格できます。Tier 3(人間)が最終的に MEMORY.md / 執筆用パスへ昇格させます。 |
--raw PATH | raw/ | デフォルトの元ソース受信場所を上書きします |
--wiki PATH | wiki/ | デフォルトの Wiki 出力先を上書きします |
--dry-run | off | 変更を加えずに、取り込み・書き込みの内容を表示します |
--force | off | lint で、自動修正(孤立ページのリンク付け、古いページへのフラグ付け)を適用します。報告のみにはしません |
--since DATE | 30 days | lint で、この日付以降に変更されたページのみを対象とします |
--index PATH | INDEX.md | インデックスの場所を上書きします |
--log PATH | LOG.md | ログの場所を上書きします |
実行フェーズ
フェーズ 1 — init
現在のプロジェクトに wiki のレイアウトがまだ存在しない場合は作成します。
<project>/
├── INDEX.md ← content catalog
├── LOG.md ← append-only operation log
├── SOUL.md ← (optional) user identity for always-load
├── CRITICAL_FACTS.md ← (optional) ~150-token always-load context
├── raw/ ← Karpathy raw layer
│ ├── articles/
│ ├── papers/
│ ├── transcripts/
│ ├── screenshots/
│ └── assets/
└── wiki/ ← Karpathy compiled layer
├── sources/ ← per-raw-doc summaries
├── entities/ ← people, orgs, products, tools
├── concepts/ ← ideas, frameworks, theories
└── synthesis/ ← cross-cutting analyses
INDEX.md と LOG.md にヘッダーを追加し、SOUL.md と CRITICAL_FACTS.md は任意のスタブとして残します。ワークフローのセクションを含む _CLAUDE.md を書き込むか、既存のファイルを更新します。冪等です。既存のレイアウトに対して再実行しても何も変更されません。
フェーズ 2 — ingest <raw-path>
各 raw ソースについて:
- 最後まで読みます(ざっと目を通すだけにしないでください)。
- 以下のフロントマターを付けて、
wiki/sources/<slug>.mdに要約ページを書き込みます。type: source raw: <path to raw file> ingested: <ISO datetime> status: draft|reviewed # draft if Tier 1, reviewed if Tier 2 - 候補となるエンティティ(人物、組織、製品、ツール)を抽出し、
wiki/entities/にスタブページを作成するか、既存のページを更新します。ソースページからのバックリンクを追加します。 - 候補となる概念(アイデア、フレームワーク)を抽出し、
wiki/concepts/にスタブページを作成するか、既存のページを更新します。 - すべての新しいページを
INDEX.mdに追加します。インデックスの更新に失敗すると、後の lint で失敗します。 LOG.mdに次の形式で追記します:YYYY-MM-DD HH:MM | <actor> | INGEST | <source slug> | <pages created> | <wikilink>- 既存の
wiki/synthesis/*ページにこのトピックを扱うものがあれば、新しいソースを反映するように改訂します。古い内容を残さないでください。
Tier 1 の制約: --tier 1 として実行する場合、すべての書き込みに status: draft を設定します。Tier 1 は wiki/synthesis/ に一切触れません(統合にはレビューが必要です)。Tier 1 は既存の status: reviewed ページを変更しません。
フェーズ 3 — query <question>
wiki から質問に回答します:
- 関連するページを
wiki/**から検索します。.agents/learnings/、.agents/findings/、および存在する場合は作成者が記述したコンテンツのディレクトリも確認します。 - 引用を付けて回答をまとめます。重要な主張にはすべて、wikilink で特定のページを引用する必要があります。
- 回答が重要な内容を含み、再度質問される可能性が高い場合は、質問、回答、引用を含む新しい
wiki/synthesis/<slug>.mdとして保存します。 LOG.mdに opQUERYで追記します。
作成者が記述したコンテンツは、wiki の下書きより優先されます。 概念がすでに .agents/findings/ または .agents/learnings/ で扱われている場合は、まずそちらを引用し、wiki は補足として扱います。
フェーズ 4 — lint
wiki/ を走査して、以下を報告します:
- 孤立ページ — 他の wiki ページからのバックリンクがなく、
INDEX.mdにも項目がないページ - 壊れた wikilink — 存在しないページを指すリンク
- 古いページ —
ingested日付が--sinceの基準日より前で、かつドメインが変化し続けているページ(ユーザーが設定した古いドメインの一覧) - 矛盾 — 相互に両立しない主張を含み、調整についての注記がない2つのページ。単純なキーワードによるヒューリスティックに加え、候補を LLM で再確認します。
- 不足している概念 —
wiki/sources/で参照されているものの、専用ページがないエンティティや概念 - インデックスのずれ —
INDEX.mdに記載されていないwiki/**内のファイル、または存在しないファイルを指すインデックス項目
検出結果を wiki/synthesis/lint-YYYY-MM-DD.md に書き込みます。デフォルトでは自動修正しません。lint は報告のみを行い、人間または Tier 2 が判断します。
--force を指定すると、自動修正します:
- 不足しているインデックス項目を追加する
- 古いページに
status: staleを設定する - 孤立ページに警告コメントを書き込む
LOG.md に op LINT で追記します。
フェーズ 5 — promote <wiki-path> --to <destination>
成熟した wiki ページを、作成者が記述したコンテンツへ移動します:
- 移動先が有効な対象(
platform-lab/patterns/*、career/*、learning/*、またはプロジェクト固有の同様の作成者コンテンツ用ディレクトリ)であることを確認します。 - 可能であれば履歴を保持するために
git mvを実行し、そうでなければ書き直します。 INDEX.mdを更新し、wiki セクションから削除して、作成者コンテンツのセクションに追加します。- 古いパスへのバックリンクをすべて探して更新します。
LOG.mdに opPROMOTEで追記します。
Tier 1 は昇格できません。 Tier 2 は wiki 内で昇格できます(status: draft → reviewed)。Tier 3(人間)は wiki から作成者コンテンツ用ディレクトリへ昇格させます。
既存の AgentOps スキルとの連携
| スキル | 連携 |
|---|---|
skills/compile | 内部の .agents/ 成果物を .agents/compiled/ に処理します。構造は llm-wiki と同じですが、内部ソースを対象とします。2つの Wiki(wiki/ と .agents/compiled/)は相互にリンクできますが、統合しません。 |
skills/research | 調査成果物で Wiki ページを引用できます。調査成果物を書く前の手順として、素材に llm-wiki ingest を任意で実行できます。 |
skills/forge | 再利用可能なパターンとして結実した Wiki ページの概念を、通常の発見事項レジストリのフローを通じて .agents/findings/ に昇格できます。 |
skills/inject | セッション開始時に、.agents/* の内容とともに関連する wiki/ ページも注入するようにします。 |
skills/post-mortem | フェーズ 2(学びの抽出)では、最近の wiki/synthesis/ ページを補足コンテキストとして活用できます。 |
skills/pre-mortem | 事前検討の対象となるドメインの過去のコンテキストを wiki/ で検索できます。 |
skills/knowledge-activation | .agents/learnings/ の昇格とともに、価値の高い Wiki ページを MEMORY.md に取り込めます。 |
AgentOps フライホイールとの関係
AgentOps フライホイールは内部の作業知識(何をしたか、何を学んだか、何がうまくいかなかったか)を蓄積します。LLM Wiki は外部から得た読書知識(何を読んだか、他者が何を明らかにしたか、最先端の状況はどうなっているか)を蓄積します。
2つのフライホイールは互いに連携します。
- Wiki ページは、内部のフライホイールに取り込まれる調査成果物から引用できます
- 内部の学びから、アプローチ X を採用した「理由」を説明する際に Wiki ページを参照できます
- 発見事項に Wiki 由来のコンテキストを補足できます
設計原則: 外部知識と内部知識は、出所が常に明確になるよう別々のツリー(wiki/ と .agents/)に保管します。2つのツリーは相互にリンクしますが、統合しません。
スケジュール設定(このスキルには含まれませんが、参照されています)
Karpathy パターンは、スキルをオンデマンドだけでなくスケジュールに沿って実行すると、最も効果を発揮します。コミュニティの実装に基づく、提案されている3層モデルは次のとおりです。
- Tier 1 — 常時稼働、低コストのローカル LLM(例:コンシューマー向け GPU 上の Gemma 4 26B A4B)。
raw/の夜間取り込み、ドラフト生成、孤立ページの検出、lint。 - Tier 2 — オンデマンドの高性能エキスパート(Claude / Codex / 同等のもの)。ドラフトの週次レビュー、統合、執筆済みコンテンツへの昇格。
- Tier 3 — 人間。長期メモリ/執筆済みコンテンツへの昇格を週次で承認します。
完全な層モデルとスケジュール設定の推奨事項については、references/architecture.md を参照してください。このスキルは層に依存しません。スケジューラーの設定はホストプロジェクトが行います。
評議会レビューに向けた未解決の質問
- Wiki の構成(
raw/、wiki/)はプロジェクトのルートに置くべきですか、それとも.agents/wiki/の下に置くべきですか? 提案の推奨:プロジェクトのルート。外部知識と内部作業を明確に区別できるためです。 skills/compileと重複する部分が多いため、2つを統合すべきですか? 提案の推奨:いいえ。別々に保ち、役割の違いを文書化します。- 3層モデルは
--tierフラグでスキルに組み込むべきですか、それとも慣例に委ねるべきですか? 提案の推奨:Tier 2 をデフォルトとする--tierフラグ。 initでSOUL.mdとCRITICAL_FACTS.mdも初期生成すべきですか、それとも任意のままにすべきですか? 提案の推奨:手順を記載したひな形として初期生成。- 適切な出力仕様はどのようなものですか? Post-mortem は
council/schemas/verdict.jsonを使いますが、llm-wikiには ingest/query/lint の結果用に独自の出力スキーマを用意すべきですか? 提案の推奨:はい。形式は評議会で決定します。
参考資料
.agents/research/2026-04-11-karpathy-llm-wiki-integration.md— このスキルの着想となった調査資料- references/architecture.md — 設計の根拠、階層モデル、相互運用性の詳細、アンチパターン
- references/research.md — 外部ソースの調査概要と統合
- Karpathy's original LLM Wiki gist (April 2026)
- コミュニティによる実装:NicholasSpisak/second-brain、eugeniughelbur/obsidian-second-brain
関連項目
skills/compile/SKILL.md— 内部アーティファクトのコンパイラー(構造的には同じパターンですが、ソースが異なります)skills/research/SKILL.md— 調査アーティファクトの作成skills/forge/SKILL.md— トランスクリプトから知識を抽出skills/inject/SKILL.md— セッション開始時のコンテキスト注入skills/post-mortem/SKILL.md— このスキルが外部へ拡張する、6 フェーズの知識フライホイール
提案のステータス:OPEN。この SKILL.md では意図する動作を説明していますが、実装はまだありません。コードを書く前に、Council によるレビュー(/pre-mortem --preset=product 経由)で設計を検証してください。承認された場合は、まず ingest フェーズと query フェーズを実装し(実験的機能としてリリース)、最初の 2 つのフェーズが検証された後で lint フェーズと promote フェーズを実装します。