llm-wiki

Karpathy の LLM Wiki

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

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

役割分担: 人間はソースを選別し、分析の方向性を示します。エージェントは要約、相互参照、ファイル整理、一貫性の維持を行います。

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

次のような場合に、このスキルを使用します。

• トピックの調査を希望している（Wiki がなければ自動的に作成してから調査を進めます）
• 新しい Wiki、ノートシステム、ナレッジベースの作成、構築、開始、構成を依頼している
• Wiki へのソースの取り込み、追加、処理を依頼している
• 質問しており、既存の Wiki がある
• Wiki の lint、監査、健全性チェックを依頼している
• 調査の文脈で、Wiki、ナレッジベース、または「ノート」に言及している

Wiki は調査のインフラであり、最終目標ではありません。 ユーザーが求めているのは調査結果です。Wiki は、調査を蓄積可能で永続的なものにするための仕組みです。 ユーザーが「X の調査を手伝って」と言い、Wiki が存在しない場合は、Wiki を作成して調査を進めます。

Wiki の保存場所

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

パスの解決

1. ユーザーがパスを指定している — そのまま使用します。
2. パスが指定されていない — コンテキストを分析して、パスを提案します。
   • ユーザーは何を調査していますか？ このトピックに合うディレクトリ名はどのようなものですか？
   • CWD のディレクトリ構造はどのようになっていますか？ 命名規則の参考になる既存のディレクトリはありますか？
   • コンテキストに合った候補を 2～3 個提案し、ユーザーの確認を待つか、独自のパスを指定してもらいます。
3. ~/ は絶対にスキャンしない — 既存の Wiki を探すためにホームディレクトリを検索してはいけません。
4. デフォルトのパスを決めつけない — 常に明示的に解決します。

User provides path → use it
    ↓ (no path)
Analyze context (topic, CWD structure, existing dirs)
    ↓
Suggest 2-3 fitting options → user confirms or gives own path
    ↓
Use confirmed path for all subsequent operations

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

wiki/
├── SCHEMA.md           # Conventions, structure rules, domain config
├── index.md            # Global catalog: topics + cross-topic pages
├── log.md              # Chronological action log (append-only, rotated at 500 entries)
├── raw/                # Layer 1: Immutable source material
│   ├── articles/       # Web articles, clippings
│   ├── papers/         # PDFs, arxiv papers
│   ├── transcripts/    # Meeting notes, interviews
│   └── assets/         # Images, diagrams referenced by sources
├── topics/             # Layer 2: Per-research-topic grouping
│   ├── {topic-slug}/
│   │   ├── concepts/   # Concepts specific to this topic
│   │   ├── entities/   # Entities specific to this topic
│   │   ├── comparisons/ # Comparisons specific to this topic
│   │   └── index.md    # Topic-level catalog
│   └── ...
├── concepts/           # Layer 2: Cross-topic concept pages
├── entities/           # Layer 2: Cross-topic entity pages
├── comparisons/        # Layer 2: Side-by-side analyses
└── queries/            # Layer 2: Filed query results worth keeping

レイヤー 1 — 生ソース: 不変です。エージェントはこれらを読み取りますが、変更することはありません。 レイヤー 2 — Wiki: エージェントが管理する Markdown ファイルです。エージェントが作成、更新、相互参照し、調査トピックごとに整理します。 レイヤー 3 — スキーマ: SCHEMA.md で構造、規約、タグの分類体系を定義します。

トピックのグループ化ルール

各調査トピックには、topics/ の下に専用のサブディレクトリを用意します。取り込み時は次のようにします。

• 単一トピックのページ（1 つの調査領域だけに関連するページ）→ topics/{topic}/concepts/、topics/{topic}/entities/、または topics/{topic}/comparisons/
• 複数トピックのページ（2 つ以上の調査領域に関連するページ）→ グローバルな concepts/、entities/、または comparisons/
• トピックページは [[wikilink]] を使ってグローバルページを参照し、その逆も同様にします。

判断基準: ソースに新しいエンティティや概念が登場したら、ほかのトピックですでに参照されているか確認します。はい → グローバルに配置します。いいえ → 現在のトピックに配置します。

2 階層のインデックス

• グローバルな index.md — すべての調査トピック（各トピックのインデックスへのリンク付き）と、複数トピックにまたがるページを一覧表示します。
• トピックの index.md — そのトピック内のすべてのページを一覧表示します。

ノートの規律（ツェッテルカステン）

Wiki ページはツェッテルカステン（カード式ノート法）の規律に従います。手法の全容については zettelkasten スキルを参照してください。対応関係は次のとおりです。

• 概念ページとエンティティページはカードです — 1 ページにつき、明確に区別されたアイデアまたはエンティティを 1 つ扱います。 行数だけでなく、アイデアの数に基づいて分割します。
• グローバル／トピックの index.md は構造ノートです — ナビゲーションを担い、アトミック性は適用されません。構造ノートの役割は 2 階層のインデックスがすべて担います。Wiki 内に別個の構造ノートファイルを作成しないでください。例外：分割後に残るページ（「要約＋リンク」、ツェッテルカステンの分割手順のステップ 4）は、小さな概念タイプのページであり、構造ノートの原則に反するものではありません。
• 比較ページとクエリページは統合ノートです — カードを組み合わせるために存在するので、アトミック性は適用されませんが、リンクのルールは適用されます。統合ページ内で生まれ、それ自体で独立して成り立つアイデアは、概念ページに昇格させる必要があります（ページの基準を参照）。統合ページをアトミック性から逃れるための隠れみのにしてはいけません。
• raw/ は文献ノートの役割を担います — ソースは変更せずに保管し、Wiki ページでは主張を独自の言葉で言い換え、出典を引用します。

ページを新規作成または更新する際は、書き込む前に毎回このチェックリストを実行してください。 分割基準の全容と具体例を含む正式版は、zettelkasten スキル（references/02-split-and-checklist.md）を参照してください。以下の要点は、そのスキルを利用できない場合の代替です。

1. アトミック性 — この追加内容は単一のアイデアですか（エンティティページの場合は、単一のエンティティですか）？
2. 分割の判断 — 次のいずれかに該当する場合は分割します：内容を網羅するためにタイトルに「および」が必要；ある段落を別の文脈で独立して引用できる；ページが複数の問いに答えている；各部分の更新頻度が異なる；被リンクからリンク先のどの点を指しているのか判断できない。分割によって自己完結性が失われる、常に一緒に引用される、または同じアイデアの単なる言い換えや例にすぎない場合は分割しません。長さ（約 200 行）は、これらの基準を適用するための警告であり、分割の理由ではありません。
3. 重複と矛盾の確認 — まず検索します。既存のアイデアがある場合は、そのページを更新します。情報が矛盾する場合は、統合して上書きせず、更新ポリシーに従います（両方の見解を記録し、contradictions／contested のマークを付け、相互にリンクします）。
4. リンク — テキスト内で用語に言及している箇所にリンクします（実質的な外部リンクを 1～2 件）。テキスト内で自然に言及されない関係は、ラベル付きの末尾セクションに記載します。リンク先のページから戻るリンクが必要か確認します。被リンクの編集は再帰的には行いません。被リンクを修正しても、そのページでチェックリストを再実行する必要はありません。
5. 構造／インデックス — トピックまたはグローバルのインデックスに、そのページの行を追加または更新します。
6. 自己完結性 — ページはソースの文脈がなくても単独で意味が通じます。
7. 独自の言葉 — 貼り付けずに言い換え、出典を引用します。

これは書き込みごとに適用する規律であり、リンター実行時に行う整理ではありません。

優先事項： この規律は llm-wiki の Wiki に適用されます。llm-wiki ではないノートリポジトリ（SCHEMA.md／index.md がないもの）で作業する場合は、そのリポジトリ独自の規約に従ってください。これはツェッテルカステンのスキルにある「現場の慣習を引き継ぐ」ルールに相当します。

既存の Wiki を再開する（重要 — 毎回必ず実施してください）

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

① SCHEMA.md を読む — ドメイン、規約、タグの分類を理解します。 ② index.md を読む — どのページがあり、それぞれどのような内容かを確認します。 ③ 最近の log.md を確認する — 直近の 20〜30 件を読み、最近の活動を把握します。 ④ 簡単な整合性チェック（手間をかけず、ずれの拡大を防ぎます）： 実際のページ数と、インデックスのヘッダーにある「Total pages」を比較します。また、 Wiki の SCHEMA.md を抜き取り確認し、現在のスキルの基準で置き換えられているルールがないかを調べます （例：「200 行で分割」を基準にするルール、「最低 2 つのリンク」、比較／クエリの適用除外の欠落）。 いずれかのチェックに失敗した場合は、書き込みの前に lint の実行または SCHEMA.md の更新を提案してください。

# Orientation reads at session start (replace <wiki> with the resolved path)
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 の作成または開始を依頼された場合：

1. Wiki のパスを解決します（上記の「Path Resolution」を参照）
2. 上記のディレクトリ構造を作成します
3. Wiki の対象ドメインをユーザーに確認します。具体的に尋ねてください
4. 取り組む予定の調査トピックを尋ねます（topics/ サブディレクトリを作成します）
5. ドメインに合わせて SCHEMA.md を作成します（下記のテンプレートを参照）
6. トピック一覧を含む初期の index.md を作成します
7. 作成記録を含む初期の log.md を作成します
8. Wiki の準備ができたことを伝え、最初に取り込む情報源を提案します

SCHEMA.md のテンプレート

ユーザーのドメインに合わせて調整します。スキーマはエージェントの動作を制約し、一貫性を保ちます。

# Wiki Schema

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

## Topics
[List research topics. Each gets a subdirectory under `topics/`.]
- topic-slug: [description]
- topic-slug: [description]

## Topic Grouping Rules
- Each research topic = `topics/{topic-slug}/` with its own `concepts/`, `entities/`, `comparisons/`, `index.md`
- Only appears in one topic → place in that topic's subdirectory
- Appears in 2+ topics → place in global `concepts/` or `entities/`
- When unsure, check existing pages across topics before placing
- Cross-topic pages should link back to all relevant topics via `[[wikilink]]`

## Conventions
- **Markdown formatting:** Wiki pages use Obsidian Flavored Markdown. For wikilinks, embeds, callouts, frontmatter properties, and other Obsidian-specific syntax, refer to the `obsidian-markdown` skill.
- **Academic sources:** For arXiv paper search, Semantic Scholar citations, and BibTeX generation, refer to the `arxiv` skill.
- **Note discipline:** Every page write runs the full seven-item Zettelkasten change checklist (atomicity, split, duplicate, links, structure/index, self-contained, own words) — refer to the `zettelkasten` skill for split criteria and linking rules.
- File names: title as filename — English content: lowercase, hyphens, no spaces (e.g., `transformer-architecture.md`); Chinese content: use the Chinese title directly (e.g., `間隔重複比集中複習有效.md`), per the `zettelkasten` skill's naming convention
- Every wiki page starts with YAML frontmatter (see below)
- Use `[[wikilinks]]` to link between pages (at least 1-2 real outbound links per page — link where the text mentions them, don't pad to hit a quota)
- 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
  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 で確立された事実として扱われるのを防げます。

タイプの管理：新しい type 値を追加する場合は、定義を 1 行で記述すること、タイトルの規約を定めること、lint の対応付けを行うことの 3 つを同時に実施する必要があります。列挙値だけを追加してはいけません。

raw/ の Frontmatter

再取り込み時に差分を検出できるよう、Raw ソースにも小さな 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つのソースで中心的な役割を果たす場合
• 既存ページに追加する：ソースで、すでに扱われている内容が言及されている場合
• ページを作成しない：通りすがりの言及、細かな詳細、または対象領域外の内容の場合
• 統合から生まれたアイデアを昇格させる — 比較ページやクエリページから、独立して成立する主張（メカニズム、一般化可能な結論）が得られた場合は、そのアイデアの概念ページを作成して該当箇所にリンクします。ページ作成の根拠となるのはソースでの登場だけでなく、Wiki 内で生まれた内容も含みます
• ページを分割する：2つ以上の異なるアイデアを扱っている場合（ツェッテルカステンの原子性については zettelkasten スキルの分割基準を参照） — 相互リンクを付けて、原子的なページに分割します。長さは警告の目安であって、分割の基準ではありません。約200行を超えるページでは分割基準を適用しますが、単一のアイデアを扱う長いページはそのままにします。比較、クエリ、インデックスページは原子性の対象外です
• ページをアーカイブする：内容が完全に古くなった場合 — _archive/ に移動し、インデックスから削除します

エンティティページ

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

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

概念ページ

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

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

比較ページ

並べて分析します。以下を含めます：

• 比較対象と、その理由
• 比較の観点（表形式を推奨）
• 結論または統合
• ソース

更新ポリシー

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

1. 日付を確認します — 一般に、新しいソースが古いソースに優先します
2. 実際に矛盾している場合は、両方の見解を日付とソースとともに記載します
3. frontmatter に矛盾を記録します：contradictions: [page-name]
4. lint レポートでユーザーによる確認が必要であることを示します
5. 矛盾が解消された場合（ユーザーの判断または決定的なソースによる）：両方のページを更新し、contested をクリアし、contradictions: から該当するペアを削除し、置き換えられた主張をアーカイブするか、その旨を明記して、解決内容を記録します

### index.md Template

Two levels: global index (wiki root) and topic index (each topic subdirectory).

**Global index.md:**

```markdown
# Wiki Index

> Global catalog. Research topics and cross-topic pages.
> Last updated: YYYY-MM-DD | Topics: N | Total pages: N

## Topics

| Topic | Pages | Index |
|-------|-------|-------|
| [topic name] | N | [[topics/{slug}/index|→ index]] |

## Cross-Topic Concepts

| Page | Summary | Topics |
|------|---------|--------|
| [[page-name]] | One-line summary | topic-a, topic-b |

## Cross-Topic Entities

| Page | Summary | Topics |
|------|---------|--------|

## Comparisons

| Page | Summary |
|------|---------|

## Queries

| Page | Summary |
|------|---------|

トピックの index.md（topics/{slug}/index.md）：

# {Topic Name} — Index

> Pages: N | Last updated: YYYY-MM-DD

## Concepts

| Page | Summary |
|------|---------|

## Entities

| Page | Summary |
|------|---------|

## Comparisons

| Page | Summary |
|------|---------|

拡張時のルール： いずれかのセクションが50項目を超えた場合は、サブセクションに分割します。

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-MM.md (year-month of rotation), start fresh.

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

コア操作

1. 取り込み

ユーザーがソース（URL、ファイル、貼り付けたテキスト）を提供したら、ウィキに取り込みます。

① ソースの生データを保存します：

• URL → defuddle（npx defuddle <url> を実行）を使ってクリーンな Markdown を抽出します。defuddle が失敗するか利用できない場合は、web_extract を代わりに使います
• PDF → defuddle（PDF をネイティブに処理）を使います。代わりに web_extract を使うこともできます
• 貼り付けたテキスト → 適切な raw/ サブディレクトリに保存します
• 内容がわかるファイル名を付けます：raw/articles/karpathy-llm-wiki-2026.md
• 生データ用のフロントマター（source_url、ingested、本文の sha256）を追加します。 同じ URL を再取り込みする場合は、sha256 を再計算して保存済みの値と比較します — 同一ならスキップし、異なる場合は差異を示して更新します。再取り込みのたびに実行しても負荷は十分小さく、 気づかれにくいソースの変更を検出できます。

② ユーザーと要点について話し合います — 何が興味深いか、その分野にとって何が重要かを確認します。 （自動処理や cron の場合は省略し、直接先に進みます。）

③ すでにあるものを確認します — index.md を検索し、search_files を使って、言及されたエンティティや概念に関する既存ページを探します。これが、ウィキを成長させることと重複ページの山にすることの違いです。

④ ウィキのページを作成または更新します：

• Zettelkasten の確認（ページを作成するたびに実施）： zettelkasten スキルの7項目の変更チェックリスト（原子性 → 分割 → 重複 → リンク → 構造 → 自己完結性 → 自分の言葉）をすべて実行します。ページが2つ以上の異なるアイデアを扱うようになっていませんか → リンクされた原子的なページに分割し、被リンクを修正して、インデックスを更新します。
• 新しいエンティティ／概念： SCHEMA.md のページ作成基準（ソースで2回以上言及されている、または1つのソースの中心となる）を満たす場合にのみ、ページを作成します
• 既存のページ： 新しい情報を追加し、事実を更新して、updated の日付を更新します。新しい情報が既存の内容と矛盾する場合は、更新ポリシーに従います。
• 相互参照： 新規ページと更新ページはすべて、本文で言及している箇所に [[wikilinks]] を使って他のページを少なくとも1〜2ページリンクします — 実際の関連性がある場合に限ります。既存ページからのリンクも確認します。
• タグ： SCHEMA.md の分類体系にあるタグのみ使用します
• 出典情報： 3つ以上のソースを統合したページでは、主張の根拠を特定のソースまでたどれる段落に ^[raw/articles/source.md] マーカーを追加します。
• 信頼度： 意見の比重が大きい、変化が速い、または単一ソースに基づく主張には、フロントマターで confidence: medium または low を設定します。複数のソースで十分に裏付けられている場合を除き、high にしないでください。

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

• 新しいページを、適切なセクションの index.md にアルファベット順で追加します
• 既存ページを更新した場合、内容に実質的な変化があれば、インデックス内の1行の概要も更新します
• インデックスのヘッダーにある「Total pages」の件数と「Last updated」の日付を更新します
• log.md に ## [YYYY-MM-DD] ingest | Source Title を追記します
• ログエントリーに、作成または更新したファイルをすべて記載します
• ログエントリーに split_decisions を記録します：分割したページ（該当した基準）と、分割しないと判断した境界的なページ（その理由）。これにより、Zettelkasten の出力契約がウィキに記録され、次のセッションで実施内容を監査できます
• links_updated を記録します：追加したバックリンクと、理由を添えて追加しないと判断したバックリンク。リンターの対称性チェックでは、記録済みの見送りペアは確認されません

⑥ 変更内容を報告します — 作成または更新したファイルをすべて列挙し、split_decisions と links_updated の記録も示します。取り込みで10ページ以上に変更を加えた場合は、セッション終了前に軽量なリンターのサブセット（リンク切れ、インデックスの網羅性、ログとの整合性）の実行を提案します。

1つのソースをきっかけに、5〜15ページのウィキページが更新されることがあります。これは正常であり、望ましいことです — 効果が積み重なっていくためです。

学術論文（arXiv + Semantic Scholar）

学術論文については、arxiv スキルを使って検索・取得します。

1. 検索：python arxiv/scripts/search_arxiv.py "topic" --sort date --max 10
2. 影響度の確認：引用数を Semantic Scholar API で確認します。

   curl -s "https://api.semanticscholar.org/graph/v1/paper/arXiv:ID?fields=citationCount,influentialCitationCount"
   

3. 読む：npx defuddle https://arxiv.org/pdf/ID（フォールバック：web_extract）
4. 取り込み：通常どおり取り込みます。生のソースは raw/papers/ に保存し、Wiki ページは標準のワークフローに従います。

論文の Wiki ページには、任意のフロントマター項目を追加します。

arxiv_id: "2402.03300"
citation_count: 150
influential_citations: 12

2. クエリ

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

① 関連ページを特定するため、index.md を読みます。 ② ページが100件以上ある Wiki では、インデックスだけでは関連する内容を見落とす可能性があるため、すべての .md ファイルを対象に search_files でキーワードも検索します。 ③ read_file を使って関連ページを読みます。 ④ まとめた知識をもとに回答を作成します。参照した Wiki ページを「[[page-a]] と [[page-b]] に基づくと……」のように明記します。 ⑤ 有用な回答はファイルに保存します。内容のある比較、詳細な解説、新たな統合的考察の場合は、queries/ または comparisons/ にページを作成します。単純な検索結果は保存せず、再度導き出すのが困難な回答のみを保存します。 ⑥ log.md にクエリと、保存したかどうかを記録します。

3. リント

ユーザーが Wiki のリント、健全性チェック、または監査を依頼した場合（また、10件以上のページに影響する取り込みの後は、先回りして提案します。取り込みの⑥を参照）、以下を確認します。(semantic, agent-run) と記された項目は、機械的なチェックではなく判断に基づく候補の報告です。誤検出を想定し、次の項目のみを報告します。

① 孤立ページ： 他のページから [[wikilinks]] でリンクされていないページを探します。

# Use execute_code for this — programmatic scan across all wiki pages
import os, re
from collections import defaultdict
wiki = "<wiki>"  # replace with resolved 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

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

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

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

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

⑥ 矛盾： 同じトピックについて、主張が食い違っているページを探します。タグやエンティティが共通しているのに異なる事実を記述しているページを確認します。contested: true または contradictions: のフロントマターがあるページはすべて抽出し、ユーザーによる確認を促します。

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

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

⑨ ページのサイズとアトミック性： 2つ以上の異なるアイデアを扱うページを、zettelkasten スキルの分割基準に沿った分割候補として報告します。約200行を超えるページは、基準を適用するよう警告します。ただし、長さだけを根拠に分割してはいけません。インデックスページは対象外です。比較・クエリページでは、アトミック性チェックの代わりに、昇格状況を抜き取り確認します（(semantic, agent-run)）：統合ページ内にのみ存在し、概念ページに昇格されていない独立したアイデアを確認します（Page Thresholds を参照）。

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

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

⑫ ログとの照合： 最近のページの updated 日付とログの項目を照合し、ログへの記録なしに変更されたページ（規律に反した書き込み）を報告します。 ⑬ リンクの対称性： 双方向リンクのマップを作成します。ログ（取り込み ⑤）に被リンクを辞退する判断が記録されているペアを除き、B から A へのリンクがない A→B のエッジを報告します。被リンクはキュレーション上の判断であるため、レビュー用に報告し、自動修正はしません。例外として、contradictions フロントマターは相互に記載されている必要があります（A が B を記載している ⇒ B も A を記載している）。ここに不整合があれば重大なエラーです。

⑭ フロントマターのリンクフィールド： contradictions:（およびページを参照するその他のフロントマターフィールド）のすべてのスラッグが既存のページを指していることを確認します。リネームやアーカイブを行うと、これらは [[wikilinks]] ではなく、ほかのチェックでも対象にならないため、参照切れが気付かれないまま残ります。

⑮ 配置ミスと昇格： 2 つ以上のトピックから参照されている topics/{t}/ ページを探します。これらはグローバルページへの昇格候補です。昇格するには、ファイル名を維持したままファイルを移動します（ファイル名ベースの [[wikilinks]] はそのまま機能します）。パス形式のリンクを修正し、両方のインデックスを更新して、移動をログに記録します。

⑯ 重複ページの検出 (セマンティック、エージェントによる実行)：タイトルが類似しているページや、タグ／エンティティを共有していて内容の重複度が高いページを探します。

⑰ 原文コピーのチェック (セマンティック、エージェントによる実行)：raw/ の内容とほぼ同一の段落を含む Wiki ページを探します。エンティティの事実、数値、出典を示すマーカーは正当に重複するため、あくまで候補として扱います。

⑱ タイトル形式と種類のスポットチェック (セマンティック、エージェントによる実行)：ページを抽出して確認します。概念ページには主張形式のタイトル、エンティティページには名称形式のタイトルが付いている必要があります。

⑲ インデックスの要約のずれ： インデックスの行を現在のページ内容と照合し、古くなった 1 行の要約にフラグを立てます。

⑳ 検出結果の報告： 具体的なファイルパスと推奨される対応を添えて、重大度別にまとめます（リンク切れ > 孤立ページ > 参照切れのフロントマタースラッグ > ソースのずれ > 意見の対立があるページ > 古い内容 > スタイル上の問題）。

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

Wiki の操作

検索

# Find pages by content (replace <wiki> with resolved path)
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>

一括取り込み

複数のソースを一度に取り込む場合は、更新をまとめて行います。

1. まずすべてのソースを読みます
2. すべてのソースから、エンティティと概念を特定します
3. それらすべてについて既存のページを確認します（N 回ではなく、検索は 1 回）
4. ページの作成／更新をまとめて行います（更新の重複を避けられます）
5. 最後に index.md を 1 回更新します
6. バッチ処理を進めながらログエントリーを追記します。最後まで保留しないでください （中断の可能性をなくせます）。ページごとの split_decisions と links_updated も含めます
7. 被リンクに関する判断は、バッチの最後に 1 回でまとめて行います（N 回ではなく 1 回。 手順 3 と同じ考え方です）

アーカイブ

内容が完全に置き換えられた場合や、対象領域が変わった場合：

1. _archive/ ディレクトリがなければ作成します
2. 元のパスを保ったまま、ページを _archive/ に移動します（例：_archive/entities/old-page.md）
3. index.md から削除します
4. そのページへのリンクを含むページを更新します。ウィキリンクをプレーンテキストと「(archived)」に置き換えます。また、そのページを参照する contradictions: やその他のフロントマターフィールドから、該当するスラッグを削除するか、別の参照先に変更します
5. アーカイブ操作をログに記録します

Obsidian との連携

Wiki ディレクトリはそのまま Obsidian の保管庫として機能します。

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

最適な結果を得るには：

• Obsidian の添付ファイルフォルダーを raw/assets/ に設定します
• Obsidian の設定で「Wikilinks」を有効にします（通常はデフォルトで有効です）
• Dataview プラグインをインストールすると、TABLE tags WHERE type = "entity" AND contains(tags, "company") のようなクエリを利用できます。フォルダーではなく、フロントマターの type で検索してください。FROM "entities" では topics/*/entities/ が対象外になります

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

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

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

セットアップ：

# 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=<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 のページ作成基準に従ってください。脚注に一度名前が出てくるだけでは、エンティティページを作成する理由になりません。
• 相互参照なしでページを作成しないでください — 孤立したページは見つけられません。すべてのページは、数合わせではなく実際の関係性を通じて、少なくとも1〜2個の他のページにリンクする必要があります。
• フロントマターは必須です — 検索、絞り込み、古さの検出に役立ちます。
• タグは分類体系に基づいて設定してください — 自由形式のタグはやがてノイズになります。新しいタグは先に SCHEMA.md に追加してから使用します。
• ページはざっと読めるようにしてください — wiki ページは30秒で読めるべきです。2つ以上の異なるアイデアを扱うページは分割してください。長さ（約200行）は分割基準を確認する目安であり、それだけを理由に分割する必要はありません。詳細な分析は専用の深掘りページに移します。
• ページを書き込むたびに Zettelkasten チェックリストを実行してください — アトミック性と分割の判断は、lint 時だけでなく書き込み時に行います。zettelkasten スキルを参照してください。
• 一括更新の前に確認してください — 取り込みによって既存ページが10件以上変更される場合は、事前にユーザーに対象範囲を確認します。
• ログをローテーションしてください — log.md が500件を超えたら、log-YYYY-MM.md に名前を変更して新しいログを開始します。エージェントは lint の際にログのサイズを確認してください。
• 矛盾は明示的に処理してください — 黙って上書きしてはいけません。両方の主張を日付とともに記録し、フロントマターに明記して、ユーザーの確認が必要であることを示します。

関連ツール

llm-wiki-compiler は、同じ Karpathy の着想に基づいてソースを概念 wiki にコンパイルする Node.js CLI です。Obsidian と互換性があるため、スケジュール実行や CLI 主導のコンパイルパイプラインを利用したいユーザーは、このスキルが管理するものと同じ保管庫を指定できます。トレードオフとして、ページ生成を担うため（ページ作成に関するエージェントの判断を置き換えます）、小規模なコーパス向けに調整されています。エージェントが関与するキュレーションを行いたい場合はこのスキルを、ソースディレクトリを一括でコンパイルしたい場合は llmwiki を使用してください。