Llm Wiki

LLM-вики по Карпати: создание и запросы к связанной markdown-базе знаний.

Метаданные навыка


Источник	Встроенный (установлен по умолчанию)
Путь	`skills/research/llm-wiki`
Версия	`2.1.0`
Автор	Hermes Agent
Лицензия	MIT
Платформы	linux, macos, windows
Теги	`wiki`, `knowledge-base`, `research`, `notes`, `markdown`, `rag-alternative`
Связанные навыки	`obsidian`, `arxiv`

Справочник: полный SKILL.md

инфо

Ниже — полное определение навыка, которое Hermes загружает при его срабатывании. Именно это агент видит как инструкции, пока навык активен.

LLM-вики Карпати

Создание и поддержание постоянной, накапливающейся базы знаний из взаимосвязанных markdown-файлов. В основе — паттерн LLM Wiki Андрея Карпати.

В отличие от традиционного RAG (который заново выискивает знания под каждый запрос), вики компилирует знание один раз и поддерживает его актуальным. Перекрёстные ссылки уже проставлены. Противоречия уже отмечены. Синтез отражает всё, что было загружено.

Разделение труда: человек подбирает источники и задаёт направление анализа. Агент пишет сводки, проставляет перекрёстные ссылки, раскладывает материал по местам и следит за согласованностью.

Когда срабатывает этот навык

Применяйте навык, когда пользователь:

Просит создать, построить или начать вики либо базу знаний
Просит загрузить, добавить или обработать источник в свою вики
Задаёт вопрос, а по настроенному пути уже лежит готовая вики
Просит проверить вики линтером, провести аудит или оценить её состояние
Упоминает свою вики, базу знаний или «заметки» в контексте исследования

Расположение вики

Расположение: задаётся через переменную окружения WIKI_PATH (например, в ~/.hermes/.env).

Если переменная не задана, по умолчанию используется ~/wiki.

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

Вики — это просто каталог markdown-файлов: открывайте его в Obsidian, VS Code или любом редакторе. Ни базы данных, ни особого инструментария не нужно.

Архитектура: три слоя

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 — сама вики: markdown-файлы, принадлежащие агенту. Он их создаёт, обновляет и связывает перекрёстными ссылками. Слой 3 — схема: SCHEMA.md задаёт структуру, соглашения и таксономию тегов.

Возобновление работы с существующей вики (КРИТИЧНО — делайте это каждую сессию)

Если у пользователя уже есть вики, сначала всегда осмотритесь, прежде чем что-либо делать:

① Прочитайте 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>

Загружать, запрашивать или линтовать стоит только после такой ориентировки. Она предотвращает:

Создание дублей страниц для уже существующих сущностей
Пропуск перекрёстных ссылок на имеющийся материал
Нарушение соглашений из схемы
Повторение уже зафиксированной в логе работы

Для больших вики (от 100 страниц) перед созданием чего-то нового ещё и быстро прогоните search_files по нужной теме.

Инициализация новой вики

Когда пользователь просит создать или начать вики:

Определите путь к вики (из переменной $WIKI_PATH, либо спросите пользователя; по умолчанию ~/wiki)
Создайте структуру каталогов, описанную выше
Спросите пользователя, какую область покрывает вики, — добивайтесь конкретики
Напишите SCHEMA.md под эту область (см. шаблон ниже)
Напишите начальный index.md с заголовком по разделам
Напишите начальный log.md с записью о создании
Подтвердите, что вики готова, и предложите первые источники для загрузки

Шаблон 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 and contested are optional but recommended for opinion-heavy or fast-moving topics. Lint surfaces contested: true and confidence: low pages for review so weak claims don’t silently harden into accepted wiki fact.

raw/ Frontmatter

Raw sources ALSO get a small frontmatter block so re-ingests can detect drift:

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

The sha256: lets a future re-ingest of the same URL skip processing when content is unchanged, and flag drift when it has changed. Compute over the body only (everything after the closing ---), not the frontmatter itself.

Tag Taxonomy

[Define 10-20 top-level tags for the domain. Add new tags here BEFORE using them.]

Example for AI/ML:

Models: model, architecture, benchmark, training
People/Orgs: person, company, lab, open-source
Techniques: optimization, fine-tuning, inference, alignment, data
Meta: comparison, timeline, controversy, prediction

Rule: every tag on a page must appear in this taxonomy. If a new tag is needed, add it here first, then use it. This prevents tag sprawl.

Page Thresholds

Create a page when an entity/concept appears in 2+ sources OR is central to one source
Add to existing page when a source mentions something already covered
DON’T create a page for passing mentions, minor details, or things outside the domain
Split a page when it exceeds ~200 lines — break into sub-topics with cross-links
Archive a page when its content is fully superseded — move to _archive/, remove from index

Entity Pages

One page per notable entity. Include:

Overview / what it is
Key facts and dates
Relationships to other entities ([[wikilinks]])
Source references

Concept Pages

One page per concept or topic. Include:

Definition / explanation
Current state of knowledge
Open questions or debates
Related concepts ([[wikilinks]])

Comparison Pages

Side-by-side analyses. Include:

What is being compared and why
Dimensions of comparison (table format preferred)
Verdict or synthesis
Sources

Update Policy

When new information conflicts with existing content:

Check the dates — newer sources generally supersede older ones
If genuinely contradictory, note both positions with dates and sources
Mark the contradiction in frontmatter: contradictions: [page-name]
Flag for user review in the lint report


### Шаблон index.md

Индекс разбит на разделы по типам. Каждая запись — одна строка: вики-ссылка плюс краткое описание.

```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
<!-- Alphabetical within section -->

## 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. Загрузка (Ingest)

Когда пользователь даёт источник (URL, файл, вставленный текст), встройте его в вики:

① Захватите сырой источник:

URL → используйте web_extract, чтобы получить markdown, и сохраните в raw/articles/
PDF → используйте web_extract (он умеет PDF) и сохраните в raw/papers/
Вставленный текст → сохраните в подходящий подкаталог raw/
Дайте файлу говорящее имя: raw/articles/karpathy-llm-wiki-2026.md
Добавьте frontmatter сырого источника (source_url, ingested, sha256 тела). При повторной загрузке того же URL: пересчитайте sha256 и сравните с сохранённым — пропустите, если совпадает; отметьте расхождение и обновите, если отличается. Операция дёшева настолько, что её стоит выполнять при каждой повторной загрузке — так ловятся незаметные изменения источника.

② Обсудите выводы с пользователем — что интересно, что важно для области. (В автоматических/cron-сценариях пропустите этот шаг и переходите дальше.)

③ Проверьте, что уже есть — поищите в index.md и через search_files существующие страницы для упомянутых сущностей и концептов. Именно это отделяет растущую вики от кучи дублей.

④ Создайте или обновите страницы вики:

Новые сущности/концепты: создавайте страницы только если они проходят пороги из раздела Page Thresholds в SCHEMA.md (упоминание в 2+ источниках или центральная роль в одном источнике)
Существующие страницы: добавьте новое, обновите факты, поднимите дату updated. Если новое противоречит имеющемуся, следуйте политике обновления (Update Policy).
Перекрёстные ссылки: каждая новая или обновлённая страница должна ссылаться минимум на 2 другие через [[wikilinks]]. Проверьте, что существующие страницы ссылаются обратно.
Теги: используйте только теги из таксономии в SCHEMA.md
Происхождение: на страницах, синтезирующих 3+ источника, добавляйте маркеры ^[raw/articles/source.md] к абзацам, чьи утверждения восходят к конкретному источнику.
Уверенность: для оценочных, быстро меняющихся или одноисточниковых утверждений ставьте confidence: medium или low во frontmatter. Не помечайте high, пока утверждение не подтверждено несколькими источниками.

⑤ Обновите навигацию:

Добавьте новые страницы в index.md в нужный раздел, по алфавиту
Обновите счётчик «Total pages» и дату «Last updated» в шапке индекса
Допишите в log.md: ## [YYYY-MM-DD] ingest | Source Title
Перечислите в записи лога каждый созданный или изменённый файл

⑥ Сообщите, что изменилось — перечислите пользователю все созданные и обновлённые файлы.

Один источник может вызвать изменения в 5–15 страницах вики. Это нормально и желательно — в этом и состоит эффект накопления.

2. Запрос (Query)

Когда пользователь задаёт вопрос по области вики:

① Прочитайте index.md, чтобы найти подходящие страницы. ② Для вики от 100 страниц дополнительно прогоните search_files по всем файлам .md по ключевым словам — одного индекса может не хватить, чтобы зацепить нужное. ③ Прочитайте подходящие страницы через read_file. ④ Соберите ответ из накопленного знания. Сошлитесь на страницы вики, которые использовали: «На основе [[page-a]] и [[page-b]]…» ⑤ Запишите ценные ответы обратно — если ответ получился как основательное сравнение, глубокий разбор или новый синтез, заведите страницу в queries/ или comparisons/. Тривиальные справки не сохраняйте — только ответы, которые тяжело вывести заново. ⑥ Обновите log.md с запросом и пометкой, был ли он сохранён.

3. Линт (Lint)

Когда пользователь просит проверить вики линтером, оценить её состояние или провести аудит:

① Страницы-сироты: найдите страницы, на которые нет входящих [[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

② Битые вики-ссылки: найдите [[links]], ведущие на несуществующие страницы.

③ Полнота индекса: каждая страница вики должна быть в index.md. Сверьте файловую систему с записями индекса.

④ Проверка frontmatter: у каждой страницы вики должны быть все обязательные поля (title, created, updated, type, tags, sources). Теги — только из таксономии.

⑤ Устаревший материал: страницы, чья дата updated старше на 90+ дней относительно самого свежего источника, упоминающего те же сущности.

⑥ Противоречия: страницы по одной теме с конфликтующими утверждениями. Ищите страницы, которые делят теги/сущности, но заявляют разные факты. Выведите на проверку пользователю все страницы с frontmatter contested: true или contradictions:.

⑦ Сигналы качества: перечислите страницы с confidence: low, а также все, что ссылаются лишь на один источник и при этом без заданного поля confidence — это кандидаты на поиск подтверждения либо на понижение до confidence: medium.

⑧ Дрейф источников: для каждого файла в raw/ с frontmatter sha256: пересчитайте хеш и отметьте несовпадения. Несовпадение означает, что сырой файл правили (так быть не должно — raw/ неизменяема) или что его загрузили из URL, который с тех пор изменился. Некритичная ошибка, но стоит сообщить.

⑨ Размер страницы: отметьте страницы длиннее 200 строк — кандидаты на разбиение.

⑩ Аудит тегов: перечислите все используемые теги, отметьте те, которых нет в таксономии SCHEMA.md.

⑪ Ротация лога: если в log.md больше 500 записей, проведите ротацию.

⑫ Отчёт о находках с конкретными путями к файлам и предлагаемыми действиями, сгруппированный по серьёзности (битые ссылки > сироты > дрейф источников > спорные страницы > устаревший материал > стилевые мелочи).

⑬ Допишите в log.md: ## [YYYY-MM-DD] lint | N issues found

Работа с вики

Поиск

# 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)
Создайте/обновите страницы за один проход (так избегаете повторных правок)
Обновите index.md один раз в конце
Напишите одну запись в лог на весь пакет

Архивирование

Когда материал полностью устарел или меняется охват области:

Создайте каталог _archive/, если его нет
Перенесите страницу в _archive/ с её исходным путём (например, _archive/entities/old-page.md)
Удалите её из index.md
Обновите все страницы, которые на неё ссылались, — замените вики-ссылку обычным текстом плюс «(archived)»
Запишите действие архивирования в лог

Интеграция с Obsidian

Каталог вики работает как хранилище Obsidian прямо из коробки:

[[wikilinks]] отображаются как кликабельные ссылки
Graph View показывает сеть знаний
YAML-frontmatter питает запросы Dataview
В папке raw/assets/ лежат изображения, на которые ссылаются через ![[image.png]]

Для лучшего результата:

Укажите в Obsidian папку вложений raw/assets/
Включите «Wikilinks» в настройках Obsidian (обычно включено по умолчанию)
Поставьте плагин Dataview для запросов вроде TABLE tags FROM "entities" WHERE contains(tags, "company")

Если рядом с этим навыком используете навык Obsidian, задайте OBSIDIAN_VAULT_PATH равным тому же каталогу, что и путь к вики.

Obsidian Headless (серверы и машины без дисплея)

На машинах без дисплея вместо десктопного приложения используйте obsidian-headless. Он синхронизирует хранилища через Obsidian Sync без графического интерфейса — то, что нужно агентам на серверах, которые пишут в вики, пока Obsidian desktop читает её на другом устройстве.

Настройка:

# 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=/home/user/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/ — источники неизменяемы. Исправления вносятся в страницы вики.
Сначала всегда осмотритесь — прочитайте SCHEMA, индекс и свежий лог перед любой операцией в новой сессии. Пропустите этот шаг — получите дубли и потерянные перекрёстные ссылки.
Всегда обновляйте index.md и log.md — без этого вики деградирует. Они составляют навигационный каркас.
Не заводите страницы для мимоходных упоминаний — следуйте порогам Page Thresholds в SCHEMA.md. Имя, мелькнувшее раз в сноске, страницы-сущности не заслуживает.
Не создавайте страницы без перекрёстных ссылок — изолированная страница невидима. Каждая должна ссылаться минимум на 2 другие.
Frontmatter обязателен — он включает поиск, фильтрацию и определение устаревания.
Теги — только из таксономии — вольные теги превращаются в шум. Сначала добавьте новый тег в SCHEMA.md, потом используйте.
Держите страницы обозримыми — страницу вики должно быть видно за 30 секунд. Разбивайте всё длиннее 200 строк. Детальный анализ выносите на отдельные тематические страницы.
Спрашивайте перед массовым обновлением — если загрузка затронет 10+ существующих страниц, сначала согласуйте охват с пользователем.
Ротируйте лог — когда в log.md больше 500 записей, переименуйте его в log-YYYY.md и начните заново. Размер лога агент проверяет при линте.
Разбирайтесь с противоречиями явно — не затирайте молча. Зафиксируйте оба утверждения с датами, отметьте во frontmatter, выведите на проверку пользователю.

Связанные инструменты

llm-wiki-compiler — CLI на Node.js, который компилирует источники в концептную вики с той же идеей Карпати в основе. Совместим с Obsidian, поэтому те, кому нужен компиляционный конвейер по расписанию или из CLI, могут направить его на то же хранилище, что ведёт этот навык. Компромиссы: инструмент берёт на себя генерацию страниц (и тем самым заменяет суждение агента о том, когда создавать страницу) и заточен под небольшие корпуса. Используйте этот навык, когда нужна курация с агентом в цикле; используйте llmwiki, когда нужна пакетная компиляция каталога источников.