jpskill.com
🛠️ 開発・MCP コミュニティ

llm-wiki-skill

Karpathy氏のLLM Wikiを基盤とし、Markdown形式の知識ベースを構築・維持し、様々な情報源を取り込み、知識を統合して検索可能にし、整合性を保つようにチェックするSkill。

📜 元の英語説明(参考)

A CLI agent skill based on Karpathy's LLM Wiki — Create and maintain a persistent, interconnected Markdown knowledge base—ingesting sources, enabling queries over compiled knowledge, and ensuring consistency through linting.

🇯🇵 日本人クリエイター向け解説

一言でいうと

Karpathy氏のLLM Wikiを基盤とし、Markdown形式の知識ベースを構築・維持し、様々な情報源を取り込み、知識を統合して検索可能にし、整合性を保つようにチェックするSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o llm-wiki-skill.zip https://jpskill.com/download/8693.zip && unzip -o llm-wiki-skill.zip && rm llm-wiki-skill.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/8693.zip -OutFile "$d\llm-wiki-skill.zip"; Expand-Archive "$d\llm-wiki-skill.zip" -DestinationPath $d -Force; ri "$d\llm-wiki-skill.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して llm-wiki-skill.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → llm-wiki-skill フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

LLM Wiki Skill

相互リンクされた Markdown ファイルで構成される永続的な知識ベースを継続的に更新および成長させます。生のコンテンツは人間によってキュレーションされ、エージェントはこのスキルを使用して、生のコンテンツを収集、重複排除、相互参照、および構造化された Markdown ファイルに要約します。このスキルは、ユーザーが以下を望む場合に有効になります。

  • Wiki または知識ベースを作成または開始する
  • 元のコンテンツを Wiki に取り込む、追加する、または処理する
  • Wiki または知識ベースについて質問する
  • Wiki をリント、監査、またはヘルスチェックして、良好な状態であることを確認する

クイックスタート

ディレクトリ構造

以下は、Wiki のディレクトリ構造のサンプルです。

llm-wiki/
├── SCHEMA.md           # レイヤー 3: ユーザーと LLM が Wiki の規則、Wiki の構造、およびタグの分類を共同で進化させるためのドキュメント
├── index.md            # SCHEMA.md の定義に関係なく、常に存在します。カテゴリ (エンティティ、コンセプトなど) ごとに整理されたすべてのカタログ。各ページはリンクと一行の要約とともにリストされています
├── log.md              # SCHEMA.md の定義に関係なく、常に存在します。時系列のアクションログ (追記のみ、年単位でローテーション)
├── raw/                # レイヤー 1: SCHEMA.md の定義に関係なく、常に存在します。人間がキュレーションした不変のコンテンツ
│   ├── documents/      # Web 記事、クリッピング、PDF
│   └── assets/         # ソースによって参照される画像、図
├── generated/          # レイヤー 2: SCHEMA.md の定義に関係なく、常に存在します。LLM によって生成されたディレクトリと Markdown ファイル
│   ├── entities/       # SCHEMA.md の定義に関係なく、常に存在します。エンティティページ (人物、組織、製品、モデル)
│   ├── topics/         # SCHEMA.md の定義に関係なく、常に存在します。トピックページ (コンセプト、用語)
│   ├── comparisons/    # 並列分析 (エンティティ間またはトピック間)

3 つのレイヤーについては、次のセクションで説明します。Wiki または知識ベースは上記の構造を使用して構築されます。ユーザーは、CLI エージェント (Codex、Claude Code、Gemini など) が llm-wiki/ フォルダのルートレベルで呼び出された場合にのみこのスキルを適用できます。これは、エージェントにスコープされたファイルシステム権限があることを意味し、SCHEMA.mdindex.mdlog.md、および raw/generated/ フォルダがその下にある必要があります。ユーザーが Wiki サブフォルダ内の他の場所で CLI エージェントを呼び出すと、このスキルは中止されます。

index.md テンプレート

インデックスはタイプ別にセクション分けされています。各エントリは 1 行です: Wiki リンク + 要約。

# Wiki インデックス

> フォーマット: `## 最終更新日: [YYYY-MM-DDThh:mm:ss] | 件名 | 合計ページ数: N`
> 件名: 用語 (エンティティ/トピック/比較など)
> 合計ページ数: 用語が言及されているページ数

## エンティティ
<!-- セクション内でアルファベット順 -->

## トピック

## 比較

log.md テンプレート

# ログファイル

> フォーマット: `## [YYYY-MM-DDThh:mm:ss] アクション | 件名 | ファイル`
> アクション: ingest, update, lint, archive, delete
> 件名: 300 文字以内で何が起こったかの要約
> ファイル: 生ドキュメントの場所、生成された Wiki などの関連ファイル
> log.md が 500 エントリを超えた場合は、ローテーションします: log-YYYY.md に名前を変更し、新たに開始します。

SCHEMA.md テンプレート

ユーザーの好みに合わせます。スキーマはエージェントの動作を制約し、一貫性を保証します。

# Wiki スキーマ

## 規則
- 生ファイルは、`entities/`、`topics/` などに存在する複数の Markdown ファイルに分割できます。
- エンティティ/トピックが 2 つ以上のソースで言及されている場合、または 1 つのソースの中心である場合にのみ、Wiki ページを作成します。
- ファイル名: 小文字、ハイフン、スペースなし (例: `transformer-architecture.md`)
- すべての Wiki ページは YAML フロントマターで始まります (下記参照)
- ページ間を相互リンクするには `[[wikilinks]]` を使用します (ページあたり最低 2 つのアウトバウンドリンク)
- 新しいページまたは更新されたページはすべて、`[[wikilinks]]` を介して少なくとも 2 つの他のページにリンクする必要があります。
- ページを更新するときは、常に `updated` の日付を更新します
- 新しい情報が既存のコンテンツと矛盾する場合:
   1. 日付を確認します — 新しいソースは一般的に古いソースに優先します
   2. 本当に矛盾する場合は、日付とソースとともに両方の立場を記述します
   3. フロントマターで矛盾をマークします: `contradictions: [page-name]`
   4. ユーザーレビューのためにフラグを立てます

## フロントマター
>  ---
>  title: ページタイトル
>  created: YYYY-MM-DDThh:mm:ss
>  updated: YYYY-MM-DDThh:mm:ss
>  type: entity | topic | comparison
>  sources: [raw/documents/source-name.md]
>  ---

## レイヤー 1 (ユーザーが指定できます。指定しない場合は、このファイルがデフォルトになります)

### ドキュメント
ユーザーがさまざまな形式で配置した単一のドキュメント

### アセット
メディアファイル、画像、ビデオリンクなど

## レイヤー 2 (ユーザーが指定できます。指定しない場合は、このファイルがデフォルトになります)

### エンティティ
注目すべきエンティティごとに 1 つの Markdown ページ。以下を含みます:
- 概要 / それが何か
- 主な事実と日付
- 他のエンティティとの関係 (`[[wikilinks]]`)
- ソース参照

### トピック
コンセプトまたはトピックごとに 1 つの Markdown ページ。以下を含みます:
- 定義 / 説明
- 知識の現状
- 未解決の質問または議論
- 関連するコンセプト (`[[wikilinks]]`)

### 比較ページ
Markdown での並列分析。以下を含みます:
- 何が比較されているのか、そしてその理由
- 比較の次元 (表形式が望ましい)
- 結論または統合
- ソース

アーキテクチャ

3 つのレイヤー

レイヤー 1 — 生コンテンツ: 不変のディレクトリとファイル。エージェントは読み取ることができますが、変更することはできません。 レイヤー 2 — Wiki または知識ベース: エージェントが所有するディレクトリと Markdown ファイル。エージェントによって作成、更新、および相互参照されます。 レイヤー 3 — スキーマ: SCHEMA.md は、llm-wiki/ の規則とタグの分類に関するユーザーの好みを定義します。

新しい Wiki を作成する

  1. ディレクトリ構造のようにディレクトリ構造を作成します。
  2. レイヤー 1 およびレイヤー 2 のディレクトリ構造に関するユーザーの好みを尋ね、ユーザーの意図を確認するためにディレクトリ構造を出力します。
  3. SCHEMA.md に基づいて規則を出力し、変更したい場合は規則に関するユーザーの好みを尋ねます。
  4. 2 と 3 に基づいて、ユーザーの好みを反映した SCHEMA.md の更新されたテンプレートを SCHEMA.md に書き込みます。
  5. index.md テンプレート に基づいて初期 index.md を書き込みます

(原文はここで切り詰められています)

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

LLM Wiki Skill

Continuously update and grow a persistent knowledge base composed of interlinked markdown files. Raw contents are curated by humans and the agent uses this skill to collect, dedupe, cross-reference and summarize raw contents into structured markdown files. This skill is activated when the user wants:

  • Create, or start a wiki or knowledge base
  • Ingest, add, or process original content into a wiki
  • Asks questions about a wiki or knowledge base
  • Lint, audit, or health-check the wiki, make sure they are in good shape

Quick Start

Directory Structure

Below is a sample wiki directory structure:

llm-wiki/
├── SCHEMA.md           # Layer 3: A document for User and LLM to co-evolve the wiki conventions, structure of wiki and tag taxonomy
├── index.md            # Always exists, regardless of SCHEMA.md definition. Catalog of everything, organizaed by categoies (entities, concepts etc), each page listed with a link and a one-line summary
├── log.md              # Always exists, regardless of SCHEMA.md definition. Chronological action log (append-only, rotated yearly)
├── raw/                # Layer 1: Always exists, regardless of SCHEMA.md definition. Immutable content curated by humans
│   ├── documents/      # Web articles, clippings, PDFs
│   └── assets/         # Images, diagrams referenced by sources
├── generated/          # Layer 2: Always exists, regardless of SCHEMA.md definition. LLM-generated directories and markdown files
│   ├── entities/       # Always exists, regardless of SCHEMA.md definition. Entity pages (people, orgs, products, models)
│   ├── topics/         # Always exists, regardless of SCHEMA.md definition. Topic pages (concepts, terms)
│   ├── comparisons/    # Side-by-side analysis (between entities or between topics)

3 layers will be explained in next secion. The Wiki or the knowledge base is built using above structure, user can ONLY apply this skill when the CLI agent (Codex, Claude Code, Gemini etc) is invoked at the llm-wiki/ folder root level given that agents have scoped file-system permissions, that means there should be SCHEMA.md, index.md, log.md and raw/, generated/ folders underneath. If user invokes CLI agent anywhere else inside the wiki subfolders this skill will abort.

index.md Template

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

# Wiki Index

> Format: `## Last Updated: [YYYY-MM-DDThh:mm:ss] | subject | Total pages: N`
> Subject: the term (entity/topic/comparison etc)
> Total pages: how many pages the term is brought up

## Entities
<!-- Alphabetical within section -->

## Topics

## Comparisons

log.md Template

# Log File

> Format: `## [YYYY-MM-DDThh:mm:ss] action | subject | files`
> Actions: ingest, update, lint, archive, delete
> Subject: the summary of what happened within 300 characters
> Files: related files such as raw documents locations, generated wikis
> When log.md exceeds 500 entries, rotate: rename to log-YYYY.md, start fresh.

SCHEMA.md Template

Adapt to the user's preference. The schema constrains agent behavior and ensures consistency:

# Wiki Schema

## Conventions
- Raw files can be broken down to several markdown files that live in `entities/`, `topics/` etc.
- Only create the wiki pages when an entity/topic is mentioned in 2+ sources or is central to one source.
- File names: lowercase, hyphens, no spaces (e.g., `transformer-architecture.md`)
- Every wiki page starts with YAML frontmatter (see below)
- Use `[[wikilinks]]` to cross-link between pages (minimum 2 outbound links per page)
- Every new or updated page must link to at least 2 other pages via `[[wikilinks]]`.
- When updating a page, always bump the `updated` date
- When new information conflicts with existing content:
   1. Check the dates — newer sources generally supersede older ones
   2. If genuinely contradictory, note both positions with dates and sources
   3. Mark the contradiction in frontmatter: `contradictions: [page-name]`
   4. Flag for user review

## Frontmatter
>  ---
>  title: Page Title
>  created: YYYY-MM-DDThh:mm:ss
>  updated: YYYY-MM-DDThh:mm:ss
>  type: entity | topic | comparison
>  sources: [raw/documents/source-name.md]
>  ---

## Layer 1 (User can specify, otherwise default to this file)

### Documents
Any single document in different formats user put in

### Assets
Any media files, images, video links etc.

## Layer 2 (User can specify, otherwise default to this file)

### Entities
One markdown page per notable entity. Include:
- Overview / what it is
- Key facts and dates
- Relationships to other entities ([[wikilinks]])
- Source references

### Topics
One markdown page per concept or topic. Include:
- Definition / explanation
- Current state of knowledge
- Open questions or debates
- Related concepts ([[wikilinks]])

### Comparison Pages
Side-by-side analysis in markdown. Include:
- What is being compared and why
- Dimensions of comparison (table format preferred)
- Verdict or synthesis
- Sources

Architecture

Three Layers

Layer 1 — Raw Contents: Immutable directory and files. The agent can read but can never modify them. Layer 2 — The Wiki or knowledge base: Agent-owned directories and markdown files. Created, updated, and cross-referenced by the agent. Layer 3 — The Schema: SCHEMA.md defines user preferences of llm-wiki/ conventions, and tag taxonomy.

Create a New Wiki

  1. Create the directory structure as in Directory Structure.
  2. Ask user preferences of Layer 1 and Layer 2 directory structures and print the directory structure to confirm user intent.
  3. Print conventions based on SCHEMA.md, ask user preferences of conventions if they want to change.
  4. Write updated template of SCHEMA.md to SCHEMA.md with user preferences based on 2 and 3.
  5. Write initial index.md based on index.md template with sectioned header.
  6. Write initial log.md based on log.md template with creation entry.
  7. Confirm the wiki is ready and suggest first sources to ingest.

Ingest original content into a Wiki

  1. Read the files in raw/ using the code block below, the output is a list of each file metadata with mtime.
python3 ./scripts/ingest.py --collect ./raw
  1. Read last line of log.md to retrieve the "date time", use the below code block to retrieve its mtime
python3 ./scripts/ingest.py --iso-to-mtime "date time"

then find files generated in step 1 that are added after the "date time". 3. Based on SCHEMA.md convetions section, summarize each newly added file. 4. Find files that are added before and on the date time to prepare for step 4 and 5. 5. For file content conflicts, refer to conventions section defined in SCHEMA.md. 6. New files are created, existing files are updated, all with newly added cross-links under generated/. 7. Update index.md with sectioned header. 8. Update log.md with creation entry. 9. List out all files that are newly added or changed for user.

Ask questions about a Wiki

  1. Find relevant headings in index.md.
  2. Locate similar pages under the Wiki and summarize them based on SCHEMA.md using the format like "Based on [[page-1]], [[page-2]], ...".
  3. present to user in markdown fashion.
  4. Ask user if they want to store the answers back in Wiki, if so take the following steps:
    • create a queries/ folder if that does not exist
    • if the question is for comparisons, put the file in comparisons/, otherwise put in queries/
  5. Update index.md with sectioned header.
  6. Update log.md with creation entry.
  7. List out all files just created to the user, filenames should be enough no need to show content.

Lint, Audit or health-check a Wiki

Note: Below are 4 rules we lint, after they are checked, add a entry in log.md with lint action, subject should be "Rules passed: N, rules failed: M, which rule failed and a brief summary within 200 characters".

  1. Always read the SCHEMA.md first, find any violations and unresolved contradictions in the wiki.
  2. Find any orphan pages that no cross-link to other pages, using below code. The output is a list of orphan page file names.
python3 ./scripts/links --orphan ./generated
  1. and find any cross-links that are broken (unreachable), using below code. The output is a dictionary of file name to all its own broken links
python3 ./scripts/links --broken ./generated
  1. Every wiki page under generated/ should be listed in index.md, flag any pages that are not listed.

Pitfalls

  • Never modify files in raw/ — sources are immutable. Corrections go in wiki pages.
  • Always orient first — read SCHEMA + index + recent log before any operation in a new session. Skipping this causes duplicates and missed cross-references.
  • Always update index.md and log.md — skipping this makes the wiki degrade. These are the navigational backbone.
  • Don't create pages without cross-references — isolated pages are invisible. Every page must link to at least 2 other pages.
  • Frontmatter is required — it enables search, filtering, and staleness detection.
  • Keep pages scannable — a wiki page should be readable in 30 seconds. Split pages over 200 lines. Move detailed analysis to dedicated deep-dive pages.
  • Ask before mass-updating — if an ingest would touch 10+ existing pages or create 10+ new pages, confirm the scope with the user first.
  • Rotate the log — when log.md exceeds 500 entries, rename it log-YYYY.md and start fresh. The agent should check log size during lint.
  • Handle contradictions explicitly — don't silently overwrite. Note both claims with dates, mark in frontmatter, flag for user review.