# Obsidian Add Summary

> Батч-заполнение frontmatter-поля summary в существующих заметках — 10–20 за сессию, с планом и подтверждением. Триггеры: «добавь/заполни/проставь summary», «прогон по summary», проект «Обогащение базы знаний». Меняет только поле summary.

- Skill: `jtprogru/obsidian-add-summary-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jtprogru/obsidian-add-summary-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jtprogru/obsidian-add-summary-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jtprogru (https://skillmd.com/u/jtprogru)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jtprogru/obsidian-add-summary-2

---


# obsidian-add-summary

Планомерное заполнение поля `summary` в существующих заметках. Полная политика — `.agents/rules/note-types-frontmatter.md`, раздел «Политика: summary как сигнал сути для агентов». Здесь — только механика батч-прохода.

## Жёсткие рамки

- **Меняется только поле `summary`** во frontmatter. Тело, теги, связи, остальные поля — не трогать.
- **`ai_generated` НЕ ставится** — до-генерация summary не делает заметку сгенерированной.
- **Непустой `summary` не перезаписывается** — если он явно противоречит телу, вынеси в отчёт, решает пользователь.
- **Батч — 10–20 заметок за сессию.** Не больше: качество summary важнее скорости, каждый требует реального чтения заметки.
- Протокол «план → подтверждение → действие» (`workflows.md`) обязателен: сначала таблица «файл → предлагаемый summary», правки — после подтверждения.

## Алгоритм

### 1. Собери кандидатов

Приоритет прогона (из проекта): концепты → литературки → карты → тезисы/эссе. Если пользователь указал папку или список файлов — работай с ними.

```bash
# Заметки без поля summary (или с пустым) в приоритетной папке
rg --files-without-match '^summary: \S' "03. Ресурсы/04. Заметки/" --glob '*.md' | head -20
```

Возьми первые 10–20. Пропускай:

- заметки с тегом `#review` / `#fleeting` — их обработает `obsidian-refactor-inbox`, summary появится при типизации
- контейнерные типы, случайно оказавшиеся в папке (см. таблицу scope в политике)

### 2. Прочитай каждую заметку целиком

Summary пишется по телу, не по имени файла. Имя claim-based часто уже хорошая основа — но проверь, что тело его подтверждает.

### 3. Сформулируй summary

Формат, стиль по типам заметок и критерий кандидата на `#needs-split` — политика `summary` в `note-types-frontmatter.md`. Если суть не ужимается в 3 предложения — summary всё равно напиши по доминирующей идее, а заметку пометь в плане как кандидата на `#needs-split`.

### 4. План → подтверждение

Покажи таблицу: файл → предлагаемый summary → пометки (кандидат на `#needs-split`, конфликт с существующим summary). Дождись подтверждения (если пользователь заранее сказал «делай сразу» — пропусти).

### 5. Примени правки

Вставляй `summary: "<текст>"` во frontmatter после `created` (если его нет — после `tags`). Если поле есть, но пустое — заполни на месте, не дублируй. Значение всегда в двойных кавычках — политика «строковые значения всегда в кавычках» в `note-types-frontmatter.md`. После прогона проверь `ruby .agents/scripts/check_frontmatter.rb .`

## Отчёт

- Сколько заполнено, сколько осталось в текущей папке (живой счётчик — Bases-вью «Без summary»)
- Кандидаты на `#needs-split` — списком
- Заметки с существующим, но противоречащим телу summary — списком, без правок

## Чек-лист

- [ ] Каждая заметка прочитана целиком перед формулировкой
- [ ] Summary соответствует политике в `note-types-frontmatter.md`
- [ ] Изменено только поле `summary`, `ai_generated` не добавлен
- [ ] Непустые summary не перезаписаны
- [ ] Кандидаты на `#needs-split` зафиксированы в отчёте (тег сам не ставится — решение за пользователем)