## Зачем вообще соединять Claude и Obsidian

Большинство людей используют Claude и Obsidian как два отдельных инструмента: заметки живут в хранилище (vault), мышление происходит в окне чата, и между ними ничего не переходит автоматически. Для разовых задач это нормально, но ломается в тот момент, когда ты ведёшь реальные проекты неделями или месяцами. Каждый раз приходится заново объяснять контекст, копипастить старые решения обратно в чат и терять нить между тем, что решил в прошлый вторник, и тем, что делаешь сегодня.

Прямое соединение Claude с твоим хранилищем Obsidian превращает заметки в рабочую память, которую модель реально может читать и писать, а не просто место, куда вставляешь текст постфактум. Практически это даёт три вещи. Первое — непрерывность: Claude может открыть заметки проекта в начале сессии вместо старта "с нуля". Второе — реальный аудиторский след: решения, навыки и исследования записываются обратно в хранилище как markdown, а не теряются в чат-логе, который просто прокручивается вниз и исчезает. Третье — накопительный эффект: каждый навык или workflow, который ты один раз выработал, становится файлом, который Claude может найти и переиспользовать в следующем проекте, вместо того чтобы изобретать заново.

Это и есть настоящая разница между "использованием ИИ-ассистента" и работой второго мозга с подключённым к нему агентом.

## Что реально нужно, чтобы связь заработала

Ничего экзотического не требуется. Рабочая схема состоит из трёх частей.

Первое — файловый MCP-коннектор (или эквивалентный локальный инструмент), который даёт Claude доступ на чтение/запись к папкам на диске, где лежит хранилище — не просто возможность открывать файлы по одному внутри самого приложения Obsidian, а полноценный листинг директорий, чтение и запись. Именно это позволяет Claude проверить статус проекта без того, чтобы ты всё пересказывал вручную.

Второе — специализированный MCP-сервер для Obsidian (их несколько, построены поверх плагина Local REST API или официального Obsidian CLI), который понимает семантику хранилища: заметки, frontmatter, теги, backlinks, дневные заметки. Именно этот слой делает поиск и работу с заметками быстрыми и дешёвыми, вместо того чтобы Claude вслепую грепал по сырым markdown-файлам.

Третье — и это как раз то, что все пропускают — письменный набор правил, который говорит Claude, как последовательно пользоваться первыми двумя пунктами. Сам по себе доступ не даёт структуры. Без правил Claude будет обращаться к файлам непоследовательно от сессии к сессии: иногда проверяя хранилище, иногда нет, в зависимости от того, как случайно сформулирован запрос.

## Точная настройка: конфиг MCP, REST API и папка, к которой реально обращается Claude

На стороне Obsidian установи community-плагин Local REST API, включи его и запиши порт и API-ключ, которые он сгенерирует — оба значения понадобятся любому MCP-серверу, который общается с Obsidian по HTTP.

```json

{

"mcpServers": {

"filesystem": {

"command": "npx",

"args": [

"-y",

"@modelcontextprotocol/server-filesystem",

"Vault\\Claude"

]

},

"obsidian": {

"command": "npx",

"args": ["-y", "mcp-obsidian"],

"env": {

"OBSIDIAN_API_KEY": "your-local-rest-api-key",

"OBSIDIAN_HOST": "127.0.0.1",

"OBSIDIAN_PORT": "27124"

}

}

}

}

```

Направь файловый сервер на корневую папку, которая содержит и хранилище, и папки проектов — а не только само хранилище. Эта деталь важнее, чем кажется: если Claude видит только vault, он может читать твои заметки, но не может при этом трогать скрипты, бэкапы и рабочие файлы конкретных проектов, которые лежат рядом.

На диске структура, которая реально выдерживает проверку временем, выглядит так (`Vault\` здесь — это твой собственный корень хранилища: синхронизируемая папка, внешний диск, путь на NAS, что угодно):

```text

Vault\Claude\

├── Claude.md # глобальные правила, читаются первыми каждую сессию

├── Rules.md # жёсткие ограничения, приоритет выше запросов

├── Claude_Projects.md # индекс активных проектов

├── Skills\ # переиспользуемые методы, один файл на навык

├── Memory\ # долгоживущие факты, с временной меткой

├── Context\ # сжатый контекст сессий, с временной меткой

├── Summary\ # итоги сессий, с временной меткой

└── Projects\

└── {ИмяПроекта}\

├── {ИмяПроекта}_claude.md # паспорт проекта: цель, правила, карта файлов

├── Context\ Memory\ Summary\ Chats\ Backup\

└── (рабочие файлы, специфичные для проекта)

```

Каждый файл с меткой использует строгий суффикс `YYYY-MM-DD_HHMM`. Это не для красоты — это значит, что ничего не перезаписывается молча, и Claude может восстановить хронологию решений просто пролистав папку.

## Claude.md: что реально должно там быть

Claude.md — это файл, который Claude читает первым каждую сессию, прежде чем трогать что-либо ещё. Держи его настолько коротким, чтобы его реально читали каждый раз, и клади туда только то, что меняет поведение Claude — не общую философию.

Обязательные разделы:

```markdown

# Claude.md

## Порядок чтения в начале сессии

1. Claude.md (этот файл)

2. Rules.md

3. Claude_Projects.md

4. Последние 3-5 файлов в Memory\, Context\, Summary\ (по дате изменения)

## Корень хранилища

Vault\Claude\ — постоянный корень второго мозга.

Skills\, Memory\, Context\, Summary\ живут здесь.

Проекты живут в Projects\{ИмяПроекта}\.

## Непреложное поведение

- Никогда не утверждать "нет доступа к файлам" без предварительного вызова

файлового/Obsidian-инструмента для проверки.

- Перед правкой существующего файла — сначала сделать бэкап с меткой времени.

- Перед началом нового проекта — провести короткое интервью для фиксации задачи.

- Отвечать напрямую, на рабочем языке, без повторения вопроса.

## Контракт структуры проекта

Каждая папка проекта обязана содержать:

{ИмяПроекта}_claude.md, Context\, Memory\, Summary\, Chats\, Backup\

```

Ключевая идея в том, что Claude.md кодирует *процесс*, а не факты. Факты (что решено, что существует) живут в Memory и паспортах проектов. Claude.md просто говорит модели, как себя вести и куда смотреть.

## Промпт для согласования, соглашения по папкам и несколько выстраданных рекомендаций

Когда проводка и файл правил уже существуют, всю остальную работу делает самое первое сообщение в новой сессии. Промпт, который стабильно даёт последовательное поведение, выглядит так:

```text

Строго следуй Claude.md и Rules.md.

Рабочая папка проекта: Vault\Claude\Projects\{ИмяПроекта}\

Прочитай паспорт проекта и последние 3 файла в его Context\, Memory\,

Summary\, прежде чем отвечать на что-либо.

Если нужного навыка нет в Skills\ — скажи об этом прямо, а не угадывай.

```

Последняя строчка важна не меньше остальных: она не даёт модели молча импровизировать workflow, когда уже существует задокументированный — и это разница между системой, которая остаётся согласованной месяцами, и той, что незаметно "плывёт" каждую сессию.

Несколько соглашений, которые стоит принять сразу:

- Один проект — одна папка, без исключений — ничего специфичного для проекта не живёт в общих корневых папках.

- Каждый выработанный навык записывается сразу при первом успешном использовании, пусть даже черновиком — во второй раз, когда он понадобится, он уже должен существовать как файл, а не как память, на которую ты надеешься у модели.

- Ни один файл не перезаписывается молча. Ставь метку времени на всё, что представляет собой решение или сессию, и позволяй старым версиям оставаться историей, а не удаляй их.

- Относись к фразе "релевантного навыка не найдено, нужно создать" как к нормальному, ожидаемому результату — а не как к провалу, — и тоже записывай этот пробел, чтобы следующая сессия не открывала его заново с нуля.

Результат — не хитрый трюк. Это скорее дисциплина, которую хочется видеть от хорошо организованного коллеги: читать перед тем как действовать, записывать то, что решил, и не заставлять следующего человека заново выводить то, что уже решено.

## Свойства заметок: что реально делает перекрёстные ссылки и граф рабочими

Ничего из вышеперечисленного не имеет значения, если сами заметки — это непрозрачные куски текста. Именно frontmatter (YAML-блок в начале заметки) плюс последовательное тегирование превращают папку markdown-файлов в настоящую базу знаний. Именно это читает Graph view в Obsidian, и именно это делает поиск Claude быстрым, а не слепым полнотекстовым сканированием.

Официальная спецификация Properties в Obsidian важна именно здесь: `tags` — это зарезервированное свойство типа List, и любое собственное списочное свойство (например, `related`) обязано следовать тому же формату — одно значение на строку, каждое с дефисом впереди, внутренние ссылки — в кавычках. Запись списка как inline-массива `[a, b, c]` сохранится, но не будет надёжно работать как свойство типа List в интерфейсе Obsidian. Заметка, достойная попасть в граф, должна нести:

```yaml

---

title: "Как соединить Claude и Obsidian"

type: skill

project: ContenFactory

tags:

- claude

- obsidian

- mcp

- second-brain

status: active

created: 2026-07-20

related:

- "[[Настройка MCP]]"

- "[[Структура Claude.md]]"

---

```

`type` и `status` здесь — обычные текстовые (Text) свойства: на практике `type` стоит ограничить значениями вроде `skill`, `project`, `research`, `decision`, `reference`, а `status` — значениями `draft`, `active`, `archived`, хотя сам Obsidian это не проверяет автоматически.

Важное уточнение, потому что это частое заблуждение: ни одно *название* свойства — ни `related`, ни `connections`, ни что-то ещё придуманное — само по себе не строит граф. Graph view и backlinks в Obsidian строятся исключительно из синтаксиса `[[wikilink]]`, где бы он ни встретился — в теле заметки или внутри любого properties-поля. Назови поле `related`, `links`, `connections` или как угодно ещё — для Obsidian это не имеет значения. Важно только то, что значение содержит настоящую ссылку `[[Имя заметки]]`, в кавычках, как показано выше. Если хочешь надёжные, осознанные зависимости в графе, рабочая рекомендация простая: выбери одно название свойства для этой цели на весь vault (чтобы поиск и шаблоны оставались последовательными) и всегда заполняй его настоящими `[[wikilink]]`-ссылками — никогда простым текстовым описанием связи.

Основную работу делают четыре поля. `type` позволяет фильтровать хранилище по виду заметки вместо пролистывания всего подряд. `tags` превращает несвязанные заметки в видимый кластер в Graph view — тег `#claude` и тег `#obsidian` на достаточном числе заметок стянут их в отдельную область графа, и ты реально увидишь, когда тема набрала достаточно материала, чтобы заслужить отдельную хаб-заметку. `related` — это ручное, осознанное простраивание обратных ссылок: не полагайся на то, что граф сам откроет связи, которые ты и так знаешь — пропиши ссылку сам, и граф лишь подтвердит её.

Привычка, которая накапливается со временем, небольшая: каждый раз при создании заметки трать десять секунд на то, чтобы дать ей тип, хотя бы один тег и одну явную ссылку на что-то связанное. Пропусти это — и получишь хранилище, где каждая заметка — остров: технически находимый поиском, но никогда не несущий реальной нагрузки ни для модели, ни для тебя.

## Как строить базу знаний, не утонув в токенах

Вот часть, которая неочевидна, пока не попробуешь на практике: дать Claude доступ к поиску по хранилищу — это почти бесплатно, а вот чтение полных заметок — нет. Один поиск по размеченному, хорошо организованному хранилищу возвращает короткий сниппет на совпадение — путь, заголовок, сто-двести символов — и это всего несколько сотен токенов суммарно. Прочитать обратно в контекст несколько полных заметок, особенно с блоками кода, стоит на порядок дороже.

Правило, которое удерживает это в разумных рамках — выведенное на практике, а не в теории: искать сначала всегда — это достаточно дёшево, чтобы делать по умолчанию перед ответом на всё, что потенциально покрыто хранилищем. Читать заметку целиком — только когда сниппета реально не хватает для ответа, и не больше одной-двух заметок за один ответ, а не "прочитать всё, что выглядит похожим". Записанное в файл правил, это добавляет всего две строчки — и именно это разница между хранилищем, которое незаметно улучшает каждый ответ, и тем, что незаметно сжигает контекстное окно каждый раз, когда вопрос касается темы, о которой ты уже писал.

База знаний строится не сваливанием заметок в папку. Она строится последовательным тегированием, достаточным для того, чтобы дешёвый поиск находил нужные три заметки вместо того, чтобы вынуждать читать все тридцать целиком.
* - статья имеет разметку markdown и вы можете её скопировать себе в Obsidian