Knowledge Research — исследуй перед записью

The Iron Law

Не записывай без ориентировки. Никогда не создавай и не обновляй файл в knowledge/ без прохождения Фазы 1. Сначала пойми тему, проверь что уже есть, согласуй направление с Виктором — потом фиксируй.

YAML — обязательно при изменении файла

Когда закончил все правки в файле knowledge/ — обнови YAML-заголовок:

• •updated: → сегодняшняя дата
• •version: → N+1
• •Касается любого изменения: содержимое, ссылки, cross-references. Одна правка или десять — version растёт на 1 за сессию.

Core Process

Содержание важнее структуры. Сначала пойми что ценного в материале. Категоризация и формат — второй шаг. Если сомневаешься в категории — предложи варианты и спроси Виктора, не трать раунды на перекладывание между папками.

Фаза 1: Сориентируйся (без веба)

Цель: понять тему и куда она ложится в knowledge/ — ДО любого веб-исследования.

Шаг 1 — Прочитай материал от Виктора. Если это ссылка — fetch только её (не глубже). Если тема/упоминание — работай с тем что есть.

Шаг 2 — Проверь knowledge/. Перед любым веб-поиском:

1. •Определи ТЕМУ (область знания), не инструмент. "Дизайн в Cowork" → тема "UI-дизайн".
2. •Прочитай ВСЕ README.md в подпапках knowledge/ (~80 строк суммарно) — определи ВСЕ затронутые категории. Секция "Границы" в каждом README подскажет куда относится материал. Не ограничивайся одной "очевидной" папкой.
3. •Для каждой затронутой категории прочитай !сводный файл — покажет знания и связи, которые Grep не найдёт.
4. •Grep по ключевым словам темы и инструмента.

Шаг 3 — Определи суть и фокус. Прежде чем лезть в веб — пойми, что в материале ценного. Workflow? Конкретный инструмент? Новый паттерн? Определи главную ценность и исследуй её. Всё остальное — контекст, который записывается как есть из источника, без отдельного исследования.

Тест ценности: Поможет ли это давать лучшие советы через полгода? Новый паттерн, инструмент, формат, подход — да. Бизнес-событие, партнёрство, цифры роста, смена руководства — нет, это новости, они устареют. Если в материале есть и новость, и знание — извлечь знание, новостную обёртку отбросить.

Шаг 4 — Доложи Виктору ориентировку:

1. •Тема — о чём это, в 1-2 предложения
2. •Куда ложится — какие категории и файлы затронуты
3. •Что уже есть — пересечения с существующими файлами
4. •Предложение — "обновить [файл]" / "новый файл [категория/имя.md]" / "не стоит записывать"
5. •Вопрос: "Нужно ли глубже исследовать в вебе, или записываем на основе того что есть?"

→ СТОП. Жди реакцию Виктора. Он может сказать:

• •"Исследуй глубже" → переходи к Фазе 2
• •"Записывай как есть" → пропускай Фазы 2-3, переходи сразу к Запиши
• •"Не надо записывать" → стоп
• •Перенаправить в другую категорию

Фаза 2: Исследуй (только после согласования)

Только если Виктор попросил углубить. Глубина зависит от типа:

Сверь с тем что уже есть. Если в knowledge/ нашлись файлы по теме — сравни с тем что нашёл в вебе. Три сценария:

• •Нет расхождений — используй как базу, не дублируй
• •Устарело — отметь что нужно обновить (конкретно что изменилось)
• •Противоречие — разберись где правда, исправь при записи

Обязательно при любом типе:

• •Пойми масштаб: это заметка на абзац или тема на отдельный файл?
• •Определи что конкретно ценного (конкретика, которой у AI нет из обучения)

Фаза 3: Доложи и обсуди

Расскажи Виктору что нашёл. Формат доклада:

1. •Суть — что это, в 2-3 предложения
2. •Что ценного — конкретика, которой у нас нет. Паттерны, инструменты, связи
3. •Связь с knowledge/ — пересекается ли с тем, что уже есть. Если да — что обновить
4. •Коллизии — если нашёл расхождения с существующими файлами, перечисли: что устарело, где противоречие
5. •Рекомендация — одна из:
   • •"Новый файл [категория/имя.md] — потому что [причина]"
   • •"Обновить существующий [файл] — потому что [причина]"
   • •"Не стоит записывать — потому что [причина]"

→ СТОП. Жди реакцию Виктора. Он может:

• •Согласиться с рекомендацией
• •Уточнить формат или объём записи
• •Перенаправить в другую категорию
• •Решить что не стоит записывать

Фаза 4: Запиши

Только после согласования:

1. Создай/обнови файл:

• •Формат — строго по knowledge/README.md (YAML-заголовок, секция "Кратко")
• •YAML: updated, version, review_by — см. правило "YAML — обязательно при изменении файла" выше
• •Файл должен быть self-contained — понятен без контекста svaib (будущая публикация)

2. Обнови файлы категории (оба!):

• •README.md — добавь новый файл в список "Файлы" с однострочным описанием
• •!название.md — интегрируй новое знание в основной текст: проверь на противоречия с существующим, замени устаревшее, сохрани целостность. Не дописывай в конец — перерабатывай. !файл = выверенная сводка знаний по теме

3. Проверь cross-references (обратные ссылки):

• •Grep по ключевым словам темы в соседних файлах knowledge/ — кто упоминает эту тему?
• •Если файл X ссылается на тему нового файла Y — добавь в X обратную ссылку на Y
• •Если в новом файле есть секция "Связанные файлы" — проверь что ссылки симметричны

НЕ вызывай context-editor — он для meta/, dev/, pub/. Для knowledge/ все проверки выше — это и есть полный чеклист

Принципы записи:

• •Без быстро устаревающего. Не записывай: точные числа stars, версии моделей (GPT-5.3, Claude 4.5), количества скиллов/плагинов, позиции в рейтингах, цены. Записывай стабильное: что это, чем отличается, как использовать, кто автор. Качественная оценка ("крупный проект") вместо количественной ("58k stars")
• •Дельта, не копия. Если у инструмента есть официальная документация — ссылайся на неё, не дублируй. Записывай то, чего в доке нет: community-паттерны, практика применения в нашем проекте, принципы выбора ("когда что использовать"). Наша копия устареет, документация — нет
• •Один файл = одна тема. Три статьи про RAG → один файл с секциями. Самостоятельная сущность (фреймворк, крупный репо) → отдельный файл
• •Не усложняй структуру раньше времени. Нет данных — нет подпапок. Когда файлов 10+ в категории — тогда думаем о подструктуре
• •Не придумывай факты — записывай что в источнике. Добавлять связи между файлами knowledge/ — ОК

Red Flags

Ты нарушаешь этот скилл если:

• •Создаёшь файл в knowledge/ не пройдя фазу исследования
• •Записываешь только то, что Виктор сказал, без собственного исследования
• •Не прочитал ВСЕ README категорий перед определением куда записывать — работал только с "очевидной" папкой
• •Не проверил что уже есть в knowledge/ по этой теме
• •Сказал "не стоит записывать" не прочитав !сводный файл категории по теме
• •Полез в веб-исследование без согласования направления с Виктором
• •Не показал Виктору доклад перед созданием файла
• •Обновляешь сводный файл простым дописыванием вместо интеграции
• •Обновил !файл, но не обновил README.md (или наоборот)
• •Забыл обновить version, updated или review_by — даже при небольших изменениях

Common Rationalizations

Quick Reference