llm-wiki

Name: llm-wiki
Author: nousresearch

github.com/nousresearch生産性258.5k612 回インストール今日更新

リポジトリ

llm-wiki について

llm-wikiは、リンクされたMarkdownファイルのナレッジベースを構築・維持するスキルです。調査内容をセッションをまたいで蓄積したい人向けに、原資料、エージェント管理のページ、スキーマを分け、取り込み・検索・監査を支援します。

主な機能

01Wikiを3層構造で整理
02原資料を変更せずに保存
03Markdownページの作成と相互リンク
04索引と作業ログの管理
05既存内容の検索と統合
06リンク・ソースの変化・品質の確認

活用シーン

01記事や論文をWikiに取り込む
02既存ページをもとに調査の質問へ回答
03リンク切れや索引漏れを監査
04ソースの変化や内容の矛盾を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nousresearch/hermes-agent --skill llm-wiki

インストール後、Claude Code で/llm-wikiを入力して読み込まれたか確認します。

詳細

Karpathy の LLM Wiki

相互にリンクされた Markdown ファイルとして、永続的で知識が積み重なるナレッジベースを構築し、維持します。 Andrej Karpathy の LLM Wiki パターンに基づいています。

従来の RAG（クエリごとに知識を一から再発見する方式）とは異なり、この Wiki は知識を一度まとめて、その内容を最新の状態に保ちます。相互参照はすでに作成されています。矛盾にはすでにフラグが付けられています。統合結果には、取り込んだすべての情報が反映されます。

役割分担： 人間は情報源を選定し、分析を指示します。エージェントは要約、相互参照、整理、一貫性の維持を行います。

このスキルが有効になるとき

次のような依頼があった場合に、このスキルを使用します。

Wiki またはナレッジベースの作成、構築、開始を依頼されたとき
Wiki への情報源の取り込み、追加、処理を依頼されたとき
質問があり、設定済みのパスに既存の Wiki があるとき
Wiki の lint、監査、健全性チェックを依頼されたとき
調査の文脈で、Wiki、ナレッジベース、または「メモ」に言及されたとき

Wiki の場所

場所： WIKI_PATH 環境変数で設定します（例：${HERMES_HOME:-~/.hermes}/.env）。

設定されていない場合は、デフォルトで ~/wiki を使用します。

WIKI="${WIKI_PATH:-$HOME/wiki}"

Wiki は Markdown ファイルを格納したディレクトリにすぎません。Obsidian、VS Code、または任意のエディターで開けます。データベースも、特別なツールも必要ありません。

アーキテクチャ：3 つのレイヤー

wiki/
├── SCHEMA.md           # Conventions, structure rules, domain config
├── index.md            # Sectioned content catalog with one-line summaries
├── log.md              # Chronological action log (append-only, rotated yearly)
├── raw/                # Layer 1: Immutable source material
│   ├── articles/       # Web articles, clippings
│   ├── papers/         # PDFs, arxiv papers
│   ├── transcripts/    # Meeting notes, interviews
│   └── assets/         # Images, diagrams referenced by sources
├── entities/           # Layer 2: Entity pages (people, orgs, products, models)
├── concepts/           # Layer 2: Concept/topic pages
├── comparisons/        # Layer 2: Side-by-side analyses
└── queries/            # Layer 2: Filed query results worth keeping

レイヤー 1 — 生の情報源： 不変です。エージェントは読み取りますが、変更することはありません。 レイヤー 2 — Wiki： エージェントが管理する Markdown ファイルです。エージェントが作成、更新し、相互参照を追加します。 レイヤー 3 — スキーマ： SCHEMA.md で構造、規約、タグ分類を定義します。

既存の Wiki を再開する（重要 — 毎回のセッションで実施）

ユーザーが既存の Wiki を持っている場合は、何かを始める前に必ず状況を把握してください。

① SCHEMA.md を読む — 対象分野、規約、タグ分類を把握します。 ② index.md を読む — どのページがあり、それぞれに何が書かれているかを把握します。 ③ 最近の log.md を確認する — 直近の 20～30 件の記録を読み、最近の活動を把握します。

WIKI="${WIKI_PATH:-$HOME/wiki}"
# Orientation reads at session start
read_file "$WIKI/SCHEMA.md"
read_file "$WIKI/index.md"
read_file "$WIKI/log.md" offset=<last 30 lines>

状況を把握してから、情報の取り込み、検索、または lint を行ってください。これにより、次のことを防げます。

すでに存在するエンティティの重複ページを作成する
既存の内容への相互参照を見落とす
スキーマの規約に反する
すでに記録されている作業を繰り返す

大規模な Wiki（100 ページ以上）では、新しい項目を作成する前に、対象のトピックを search_files で簡単に検索してください。

新しい Wiki を初期化する

ユーザーから Wiki の作成または開始を依頼された場合：

Wiki のパスを決定します（$WIKI_PATH 環境変数から取得するか、ユーザーに尋ねます。デフォルトは ~/wiki）
上記のディレクトリ構造を作成します
Wiki の対象分野をユーザーに具体的に尋ねます
対象分野に合わせて SCHEMA.md を作成します（以下のテンプレートを参照）
セクション分けされたヘッダーを含む初期 index.md を作成します
作成記録を含む初期 log.md を作成します
Wiki の準備ができたことを伝え、最初に取り込む情報源を提案します

SCHEMA.md テンプレート

ユーザーの対象分野に合わせて調整します。スキーマはエージェントの動作を制約し、一貫性を確保します。

# Wiki Schema

## Domain
[What this wiki covers — e.g., "AI/ML research", "personal health", "startup intelligence"]

## Conventions
- File names: lowercase, hyphens, no spaces (e.g., `transformer-architecture.md`)
- Every wiki page starts with YAML frontmatter (see below)
- Use `[[wikilinks]]` to link between pages (minimum 2 outbound links per page)
- When updating a page, always bump the `updated` date
- Every new page must be added to `index.md` under the correct section
- Every action must be appended to `log.md`
- **Provenance markers:** On pages that synthesize 3+ sources, append `^[raw/articles/source-file.md]`
  at the end of paragraphs whose claims come from a specific source. This lets a reader trace each
  claim back without re-reading the whole raw file. Optional on single-source pages where the
  `sources:` frontmatter is enough.

## Frontmatter
  ```yaml
  ---
  title: Page Title
  created: YYYY-MM-DD
  updated: YYYY-MM-DD
  type: entity | concept | comparison | query | summary
  tags: [from taxonomy below]
  sources: [raw/articles/source-name.md]
  # Optional quality signals:
  confidence: high | medium | low        # how well-supported the claims are
  contested: true                        # set when the page has unresolved contradictions
  contradictions: [other-page-slug]      # pages this one conflicts with
  ---

confidence と contested は任意ですが、意見が多いトピックや変化の速いトピックでは推奨されます。Lint では contested: true と confidence: low のページが確認対象として表示されるため、根拠の弱い主張がいつの間にか Wiki の確定事項として定着するのを防げます。

raw/ の Frontmatter

生の情報源にも小さな frontmatter ブロックを追加し、再取り込み時に変化を検出できるようにします。

---
source_url: https://example.com/article   # original URL, if applicable
ingested: YYYY-MM-DD
sha256: <hex digest of the raw content below the frontmatter>
---

sha256: を使うと、同じ URL を将来再取り込みする際に、内容が変わっていなければ処理を省略し、変更されていれば変化を検出できます。ハッシュは本文のみ（閉じる --- より後のすべて）を対象に計算し、frontmatter 自体は含めません。

タグの分類体系

［この分野の最上位タグを10〜20個定義してください。新しいタグは、使用する前にここに追加してください。］

AI/ML の例：

モデル：model、architecture、benchmark、training
人物／組織：person、company、lab、open-source
技術：optimization、fine-tuning、inference、alignment、data
メタ：comparison、timeline、controversy、prediction

ルール：各ページで使用するタグは、すべてこの分類体系に含まれている必要があります。新しいタグが必要な場合は、まずここに追加してから使用してください。これにより、タグの増殖を防げます。

ページ作成の基準

ページを作成する：あるエンティティ／概念が2つ以上のソースに登場する、または1つのソースで中心的に扱われている場合
既存のページに追加する：ソースで、すでに取り上げている内容に言及している場合
ページを作成しない：軽く触れられているだけの場合、細かな情報の場合、または対象分野外の場合
ページを分割する：約200行を超えた場合。サブトピックに分け、相互リンクを追加してください
ページをアーカイブする：内容が完全に置き換えられた場合。_archive/ に移動し、インデックスから削除してください

エンティティページ

注目すべきエンティティごとに1ページ作成します。以下を含めてください。

概要／概要説明
主な事実と日付
他のエンティティとの関係（[[wikilinks]]）
ソースの参照

概念ページ

概念またはトピックごとに1ページ作成します。以下を含めてください。

定義／説明
現在の知見
未解決の疑問や議論
関連する概念（[[wikilinks]]）

比較ページ

項目を並べて分析します。以下を含めてください。

比較対象とその理由
比較する観点（表形式を推奨）
結論または総合的な見解
ソース

更新ポリシー

新しい情報が既存の内容と矛盾する場合：

日付を確認してください。一般に、新しいソースが古いソースに優先します
実際に矛盾している場合は、両方の見解を日付とソースとともに記載してください
frontmatter に矛盾を記載してください：contradictions: [page-name]
lint レポートでユーザーによる確認が必要な項目としてフラグを立ててください


### index.md Template

The index is sectioned by type. Each entry is one line: wikilink + summary.

```markdown
# Wiki Index

> Content catalog. Every wiki page listed under its type with a one-line summary.
> Read this first to find relevant pages for any query.
> Last updated: YYYY-MM-DD | Total pages: N

## Entities


## Concepts

## Comparisons

## Queries

拡張ルール： セクションの項目数が50を超えた場合は、先頭の文字またはサブドメインごとにサブセクションへ分割してください。インデックス全体が200項目を超えた場合は、ページをテーマ別にまとめてすばやく移動できるよう、_meta/topic-map.md を作成してください。

log.md のテンプレート

# Wiki Log

> Chronological record of all wiki actions. Append-only.
> Format: `## [YYYY-MM-DD] action | subject`
> Actions: ingest, update, query, lint, create, archive, delete
> When this file exceeds 500 entries, rotate: rename to log-YYYY.md, start fresh.

## [YYYY-MM-DD] create | Wiki initialized
- Domain: [domain]
- Structure created with SCHEMA.md, index.md, log.md

主要な操作

1. 取り込み

ユーザーがソース（URL、ファイル、貼り付けたテキスト）を提供したら、Wikiに統合します。

① 元のソースを保存します：

URL → web_extract を使ってMarkdownを取得し、raw/articles/ に保存します
PDF → web_extract（PDFに対応）を使い、raw/papers/ に保存します
貼り付けたテキスト → 適切な raw/ サブディレクトリに保存します
内容を表すファイル名を付けます：raw/articles/karpathy-llm-wiki-2026.md
元データのフロントマター（source_url、ingested、本文の sha256）を追加します。同じURLを再取り込みする場合は、sha256 を再計算して保存済みの値と比較します — 一致していればスキップし、異なっていれば差分を記録して更新します。毎回の再取り込み時に実行しても負荷は小さく、気付かないうちにソースが変更されるのを検出できます。

② 要点についてユーザーと話し合います — 興味深い点や、その分野で重要な点を確認します。（自動化／cronのコンテキストでは省略し、直接次に進みます。）

③ 既存の内容を確認します — index.mdを検索し、search_files を使って、言及されたエンティティや概念に関する既存ページを探します。これにより、Wikiが重複ページの山になるのを防ぎ、着実に成長させられます。

④ Wikiページを作成または更新します：

新しいエンティティ／概念： SCHEMA.mdのページ作成基準（2つ以上のソースで言及、または1つのソースで中心的なテーマ）を満たす場合にのみページを作成します
既存のページ： 新しい情報を追加し、事実を更新して、updated の日付を更新します。新しい情報が既存の内容と矛盾する場合は、更新ポリシーに従います。
相互参照： 新規または更新するすべてのページから、[[wikilinks]] を使って少なくとも2つの他のページにリンクします。既存のページからリンクが戻っていることも確認します。
タグ： SCHEMA.mdの分類体系にあるタグのみを使用します
出典情報： 3つ以上のソースを統合するページでは、主張の出典が特定のソースにたどれる段落に ^[raw/articles/source.md] マーカーを追加します。
確信度： 意見が多いもの、変化が速いもの、または単一ソースに基づく主張については、フロントマターの confidence: medium または low を設定します。複数のソースで十分に裏付けられている場合を除き、high としないでください。

⑤ ナビゲーションを更新します：

新しいページをindex.mdの適切なセクションにアルファベット順で追加します
indexのヘッダーにある「Total pages」の件数と「Last updated」の日付を更新します
log.md に追記します：## [YYYY-MM-DD] ingest | Source Title
ログ項目に、作成または更新したすべてのファイルを記載します

⑥ 変更内容を報告します — 作成または更新したすべてのファイルをユーザーに伝えます。

1つのソースによって、5〜15件のWikiページが更新されることもあります。これは通常のことであり、望ましい結果です。知識が積み重なっていく効果です。

2. 質問への回答

ユーザーがWikiの対象分野について質問した場合：

① 関連ページを特定するため、index.md を読みます。 ② 100ページ以上あるWikiでは、主要な用語についてすべての .md ファイルを search_files で検索します — indexだけでは関連する内容を見落とす可能性があります。 ③ read_file を使って関連ページを読みます。 ④ まとめた知識から回答を作成します。参照したWikiページを「[[page-a]] と [[page-b]] に基づくと……」のように示します。 ⑤ 価値のある回答をファイルに保存します — 内容のある比較、詳細な調査、または新しい統合的知見を含む場合は、queries/ または comparisons/ にページを作成します。簡単に調べられる内容は保存せず、再導出に手間がかかる回答のみを対象にします。 ⑥ 質問内容と、その回答をファイルに保存したかどうかを log.md に記録します。

3. リント

ユーザーから Wiki のリント、ヘルスチェック、または監査を依頼された場合：

① 孤立ページ： 他のページからの [[wikilinks]] によるリンクがないページを探します。

# Use execute_code for this — programmatic scan across all wiki pages
import os, re
from collections import defaultdict
wiki = "<WIKI_PATH>"
# Scan all .md files in entities/, concepts/, comparisons/, queries/
# Extract all [[wikilinks]] — build inbound link map
# Pages with zero inbound links are orphans

② リンク切れの Wiki リンク： 存在しないページを指す [[links]] を探します。

③ インデックスの完全性： すべての Wiki ページが index.md に記載されている必要があります。ファイルシステムとインデックスの項目を照合します。

④ フロントマターの検証： すべての Wiki ページに、必須フィールド（title、created、updated、type、tags、sources）がすべて含まれている必要があります。タグは分類体系に準拠している必要があります。

⑤ 古いコンテンツ： 同じエンティティに言及する最新のソースよりも、updated の日付が90日を超えて古いページ。

⑥ 矛盾： 同じトピックを扱い、主張が食い違うページ。タグやエンティティを共有しながら異なる事実を述べているページを探します。contested: true または contradictions: がフロントマターにあるすべてのページを、ユーザーの確認用に提示します。

⑦ 品質の指標： confidence: low のページと、単一のソースしか引用していないのに confidence フィールドが設定されていないページを一覧表示します。これらのページは、裏付けを探すか、confidence: medium に引き下げる候補です。

⑧ ソースのドリフト： sha256: がフロントマターにある raw/ 内の各ファイルについて、ハッシュを再計算し、不一致があれば報告します。不一致は、raw ファイルが編集された（本来あってはならず、raw/ は不変です）か、以降変更された URL から取り込まれたことを示します。重大なエラーではありませんが、報告する価値があります。

⑨ ページサイズ： 200行を超えるページを、分割候補として報告します。

⑩ タグ監査： 使用中のタグをすべて一覧表示し、SCHEMA.md の分類体系にないものを報告します。

⑪ ログのローテーション： log.md の項目が500件を超えている場合、ローテーションします。

⑫ 検出結果の報告： 具体的なファイルパスと推奨される対応を添えて、重大度別（リンク切れ > 孤立ページ > ソースのドリフト > 異議のあるページ > 古いコンテンツ > スタイル上の問題）にまとめて報告します。

⑬ log.md に追記： ## [YYYY-MM-DD] lint | N issues found

Wiki の操作

検索

# Find pages by content
search_files "transformer" path="$WIKI" file_glob="*.md"

# Find pages by filename
search_files "*.md" target="files" path="$WIKI"

# Find pages by tag
search_files "tags:.*alignment" path="$WIKI" file_glob="*.md"

# Recent activity
read_file "$WIKI/log.md" offset=<last 20 lines>

一括取り込み

複数のソースを一度に取り込む場合、更新をまとめて処理します：

まずすべてのソースを読み取ります
すべてのソースに含まれるエンティティと概念を特定します
それらすべてについて既存のページを確認します（N回ではなく、1回の検索で行います）
1回の処理でページを作成・更新します（冗長な更新を避けます）
最後に index.md を一度だけ更新します
バッチ全体を記録するログエントリーを1つ書き込みます

Obsidian との連携

Wiki ディレクトリは、追加設定なしですぐに Obsidian の保管庫として機能します：

[[wikilinks]] がクリック可能なリンクとして表示されます
グラフビューでナレッジネットワークを可視化できます
YAML フロントマターを Dataview クエリで利用できます
raw/assets/ フォルダーには、![[image.png]] で参照される画像を格納します

最適な結果を得るには：

Obsidian の添付ファイルフォルダーを raw/assets/ に設定します
Obsidian の設定で「Wikilinks」を有効にします（通常はデフォルトで有効です）
TABLE tags FROM "entities" WHERE contains(tags, "company") のようなクエリを使うため、Dataview プラグインをインストールします

このスキルと併せて Obsidian スキルを使う場合は、OBSIDIAN_VAULT_PATH を Wiki のパスと同じディレクトリに設定します。

Obsidian Headless（サーバーおよびヘッドレスマシン）

ディスプレイのないマシンでは、デスクトップアプリの代わりに obsidian-headless を使用します。 GUI なしで Obsidian Sync 経由の保管庫同期ができるため、別のデバイスで Obsidian デスクトップアプリを使いながら、サーバー上で Wiki に書き込むエージェントの実行に最適です。

セットアップ：

# Requires Node.js 22+
npm install -g obsidian-headless

# Login (requires Obsidian account with Sync subscription)
ob login --email <email> --password '<password>'

# Create a remote vault for the wiki
ob sync-create-remote --name "LLM Wiki"

# Connect the wiki directory to the vault
cd ~/wiki
ob sync-setup --vault "<vault-id>"

# Initial sync
ob sync

# Continuous sync (foreground — use systemd for background)
ob sync --continuous

systemd によるバックグラウンドでの継続的な同期：

# ~/.config/systemd/user/obsidian-wiki-sync.service
[Unit]
Description=Obsidian LLM Wiki Sync
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/path/to/ob sync --continuous
WorkingDirectory=%h/wiki
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now obsidian-wiki-sync
# Enable linger so sync survives logout:
sudo loginctl enable-linger $USER

これにより、サーバー上の ~/wiki にエージェントが書き込みながら、ノートパソコンやスマートフォンの Obsidian で同じ保管庫を閲覧できます。変更は数秒以内に反映されます。

注意点

raw/ 内のファイルは絶対に変更しないでください — ソースは不変です。修正は Wiki ページに記載します。
まず必ず状況を把握してください — 新しいセッションで操作を行う前に、SCHEMA、インデックス、直近のログを読みます。これを省くと、重複や相互参照の見落としにつながります。
index.md と log.md は必ず更新してください — 更新を省くと、Wiki の品質が低下します。これらはナビゲーションの基盤です。
一度だけ言及された内容のページは作成しないでください — SCHEMA.md のページ作成基準に従います。脚注に一度登場する名前に、エンティティページを作る必要はありません。
相互参照のないページは作成しないでください — 孤立したページは見つけられません。すべてのページから、少なくとも 2 つの他のページにリンクしてください。
フロントマターは必須です — 検索、フィルタリング、陳腐化の検出に役立ちます。
タグは分類体系から選んでください — 自由形式のタグはノイズになります。新しいタグはまず SCHEMA.md に追加してから使用してください。
ページはざっと読めるようにしてください — Wiki ページは 30 秒で読める長さにします。200 行を超えるページは分割してください。詳細な分析は、専用の詳細解説ページに移します。
一括更新の前には確認してください — 取り込みによって既存のページが 10 件以上変更される場合は、まずユーザーに対象範囲を確認します。
ログをローテーションしてください — log.md が 500 件を超えたら、log-YYYY.md に名前を変更して新しいログを開始します。エージェントは lint の際にログのサイズを確認してください。
矛盾には明示的に対処してください — 黙って上書きしないでください。両方の主張を日付とともに記載し、フロントマターに印を付けて、ユーザーの確認を求めます。

基本情報

作者: nousresearch
リポジトリ: nousresearch/hermes-agent
カテゴリ: 生産性
インストール数: 612
GitHub スター: 258,486

問題を報告