Research

Research — скилл качественного LLM-исследования

Зачем этот скилл

LLM-ресёрч без методологии порождает красивые, но ненадёжные результаты: галлюцинации выглядят как факты, коммерческий контент маскируется под best practices, vocal minority подменяет реальную картину. Этот скилл применяет проверенную методологию, чтобы результат был не только полным, но и достоверным — и сохраняет его в базу знаний, чтобы работа не пропала с закрытием чата.

Полная методология с источниками: 03_knowledge/llm-research-methodology.md. Прочитай её перед первым использованием скилла, чтобы понимать теоретическую базу. Ниже — операционный протокол.

Фаза 0. Классификация запроса

Перед началом определи тип исследования — от него зависит глубина, критерии остановки и формат результата.

Исследование-знание («Как устроены Personal CRM?») → Широкий обзор, множество точек зрения, максимальный охват. Критерий остановки: насыщение (новые запросы не дают новой информации).

Исследование-решение («Какую CRM мне выбрать?») → Узкий фокус на ограничениях пользователя, чёткие критерии, быстрый выход на действие. Критерий остановки: достаточно данных для принятия решения.

Зафиксируй тип в начале работы. Типичная ловушка: начать с решения, скатиться в бесконечное накопление знаний.

Для исследования-решения сразу уточни у пользователя:

• Какие критерии выбора?
• Какие ограничения (бюджет, время, навыки, экосистема)?
• Какой допустимый уровень неопределённости?

Создай файл результата ДО начала сбора (обязательно)

🛑 Это действие выполняется СЕЙЧАС, до перехода к Фазе 1. Если файл не создан — дальше не двигайся.

1. Определи имя файла: research-{тема-kebab-case}.md
2. Определи путь по task-routing-модели (см. task-routing-methodology-2026-04.md §2):
   • Standalone ресёрч (переживёт любой проект, переиспользуемое знание) → 03_knowledge/
   • Ресёрч в контексте проекта, но знание переиспользуемое → 03_knowledge/, а из <project>/context.md ставь ссылку. Не дублируй в папку проекта.
   • Ресёрч, тесно привязанный к проекту и не переиспользуемый (например, конкретные цифры по одному клиенту) → <project>/research/
   • Если знание меняет вектор проекта (новый вариант решения, пересмотр подхода) — в <project>/plan.md добавляется open question или Contingency ветка со ссылкой на research-файл
3. Зафиксируй resolved path целиком: <директория>/<filename>.md. Это и есть канонический путь документа для frontmatter, индексации и мультисессионного продолжения.
4. Создай файл с YAML-frontmatter из шаблона Фазы 4 (тело пока пустое)
5. Добавь в TodoList задачу: «Записать результат в {resolved_path}»
6. Сообщи пользователю: «Результат буду писать в {resolved_path}»

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

Правило: ресёрч НЕ пишется в <project>/tasks.md (это execution queue) и НЕ пишется в <project>/context.md (это инварианты проекта, не методология). context.md может содержать только ссылку на research-файл.

Фаза 1. Декомпозиция

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

Покажи пользователю декомпозицию перед началом работы: «Разбил вопрос на N подвопросов: [список]. Что-то пропустил?»

Фаза 2. Сбор данных

Для каждого подвопроса

1. Web search первым ходом. Начинай с поиска, а не с генерации из головы. Это принцип source-first — от фактов к выводам, не наоборот. Ищи разнообразные источники: академические, практические, отраслевые.

2. Учитывай карту искажений при сборе:

   Искажение	Как проявляется	Что делать
   Vocal minority	SEO-контент и мнения «крикунов» доминируют	Спроси: «Что делает типичный пользователь, который не пишет постов?»
   Survivorship bias	Только success stories, нет провалов	Спроси: «Кто НЕУСПЕШНО пробовал? Типичные причины провала?»
   Authority bias	Перевес FAANG/McKinsey, игнор малого бизнеса	Спроси: «Как это решается в компаниях до 50 человек?»
   Commercial noise	Контент-маркетинг маскируется под best practice	Спроси: «Кто из отвечающих имеет коммерческий интерес?» Запрашивай принципы, не инструменты
   Языковое смещение	Западные паттерны по умолчанию	Явно указывай географию. Часть запросов на EN для доступа к другому пласту данных
   Recency bias	Устаревшая или наоборот хайповая информация	Спроси: «Актуально ли на [дату]? Как менялось за 3 года?»

3. Маркируй уверенность. Для каждого утверждения оценивай:

   • ✅ подтверждено множеством независимых источников
   • ⚠️ есть в нескольких источниках, но спорно
   • ❓ предположение на основе паттернов
   • 🔴 не удалось подтвердить

4. Классифицируй источники. Для каждого: академический / независимый практический / коммерческий (контент-маркетинг). Это помогает пользователю оценить надёжность.

Фаза 3. Верификация

После сбора данных — проверка на прочность. Не пропускай эту фазу, даже если кажется, что всё очевидно.

1. Chain of Verification. Перечисли ключевые фактические утверждения. Для каждого: насколько уверен? Какой источник? Проверь через web search самые критичные.

2. Adversarial check. Задай себе:

   • Какой самый сильный аргумент ПРОТИВ этих выводов?
   • Какие blind spots у этого исследования?
   • Если бы скептически настроенный эксперт это прочитал — что бы он сказал?

3. Проверка собственного bias исследователя. Убедись:

   • Вопросы были нейтральными (не наводящими)
   • Первый полученный ответ не стал якорем для всего исследования
   • Рассмотрены разные фреймы (плюсы И минусы, не только одна сторона)

Фаза 4. Синтез → файл

Результат исследования пишется сразу в файл, созданный в Фазе 0. НЕ в чат, НЕ в существующий рабочий артефакт — только в свой файл.

Структура результата

---
id: <kebab-case-id>
type: note
status: active
created: <YYYY-MM-DD>
updated: <YYYY-MM-DD>
aliases:
  - "<Понятное название на русском>"
tags: [knowledge, research, <тематические теги>]
source_path: "<resolved_path_from_phase_0>"
freshness: seasonal
expires: <+6 месяцев от создания>
research_type: knowledge | decision
confidence: low | medium | high
---

# <Название исследования>

## Суть
<1-3 предложения: что исследовано, для чего, ключевой вывод>

## Детали

### TL;DR
<5-7 пунктов: главные находки>

### <Раздел 1>
<Содержание с маркировкой уверенности ✅/⚠️/❓/🔴>

### <Раздел N>

### Альтернативные точки зрения
<Контраргументы, несогласные позиции>

### Blind spots и ограничения
<Что не покрыто, где данные слабые, что может измениться>

## Источники

### Академические
- [Название](./URL) — краткое описание

### Практические
- [Название](./URL) — краткое описание

### Коммерческие (учитывать bias)
- [Название](./URL) — краткое описание, чей продукт продвигает

## Следующий шаг
<Что делать с результатами: решение, дополнительное исследование, конкретное действие>

Правила оформления

• Русский язык, если пользователь не просит иначе
• Конкретные цифры и факты, а не общие слова
• Каждое утверждение с маркировкой уверенности
• Источники разделены по типу (академические / практические / коммерческие)
• Секция «Blind spots» обязательна — честность про ограничения важнее иллюзии полноты

🛑 СТОП перед ответом пользователю. Не отправляй результат в чат, пока не выполнена Фаза 5. Проверь: файл из Фазы 0 заполнен? Индексы обновлены? Только после этого — ответ в чат со ссылкой на файл.

Фаза 5. Сохранение и индексация (ОБЯЗАТЕЛЬНО)

Результат исследования всегда сохраняется в отдельный файл. Это не опционально — ресёрч по определению проходит тройной фильтр (переиспользуемость + уникальность + объём).

Файл уже создан в Фазе 0 и заполнен в Фазе 4. Осталось связать его с остальной базой.

Протокол сохранения

1. Проверь, что файл заполнен. Файл из Фазы 0 должен содержать полный результат по шаблону. Если ты написал результат в чат или в другой файл — это ошибка. Перенеси в правильный файл прямо сейчас.

2. Обнови индексы в порядке медленные → быстрые слои (см. write-protocol.md §5):

   • 03_knowledge/README.md — добавь ссылку, если файл в 03_knowledge/
   • <project>/plan.md — если ресёрч меняет вектор проекта (новая ветка Contingency / open question / Drift Guard запись)
   • <project>/context.md — ссылка, если ресёрч привязан к проекту и вводит устойчивый инвариант
   • <project>/log.md — запись о проведённом исследовании с датой и темой
   • <project>/tasks.md НЕ обновляется, если не появился новый execution-шаг
   • Если ресёрч дал open question, требующее действия от сотрудника — запись идёт в 01_now/ops/<contour>/delegations/<slug>.md, не в tasks проекта

3. Свяжи с контекстом. Если в базе есть связанные документы — добавь перекрёстные ссылки.

4. Не спрашивай «сохранить?» — просто сохраняй и сообщи пользователю, куда.

5. В чат — только ссылку + TL;DR (3-5 пунктов). Полный результат — в файле.

Фаза 6. Чеклист качества (перед финализацией)

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

• Есть ссылки на первоисточники (не только блоги)?
• Представлены альтернативные точки зрения?
• Отмечены утверждения с низкой уверенностью?
• Ключевые факты проверены через web search?
• Выявлены потенциальные commercial biases?
• Учтена vocal minority vs silent majority?
• Проверено на survivorship bias (есть примеры неудач)?
• Результат релевантен ситуации ПОЛЬЗОВАТЕЛЯ (а не generic best practice)?
• Информация актуальна на текущую дату?
• Указаны blind spots исследования?
• Нейтральная формулировка вопросов (не confirmation bias)?
• Учтено языковое/культурное смещение?
• Определён тип (знание vs решение) и критерии остановки?
• Результат записан в ОТДЕЛЬНЫЙ файл (созданный в Фазе 0), а НЕ в чат / рабочий артефакт?
• Индексы обновлены (README, context.md, log.md)?

Антипаттерны (чего НЕ делать)

• Генерировать «из головы» без web search. Source-first — сначала факты, потом выводы.
• Выдавать один длинный ответ без структуры. Декомпозиция → сбор → верификация → синтез.
• Пропускать adversarial check. Даже если результат выглядит убедительно.
• Забывать сохранить. Ресёрч без сохранения в базу = потерянная работа.
• Писать результаты ресёрча в существующий рабочий артефакт. Если ты проводишь исследование для задачи (таксономия, архитектура, выбор стека) — результат ресёрча НЕ пишется в артефакт задачи. Артефакт ССЫЛАЕТСЯ на ресёрч-файл. Исследование переживает задачу и имеет самостоятельную ценность. Правило: ≥3 источников или ≥500 слов аналитики = отдельный файл, всегда.
• Скатываться в over-researching. Три источника говорят одно и то же → насыщение → остановка.
• Пересказывать результаты прошлых сессий своими словами. Это вносит bias пересказчика. Ссылайся на сохранённый документ.
• Рекомендовать конкретные коммерческие продукты без оговорок. Описывай критерии выбора, а не бренды.

Мультисессионный протокол

Если исследование продолжается из предыдущей сессии:

1. Прочитай сохранённый документ по его resolved path из Фазы 0 / frontmatter source_path — это контекст.
2. Не повторяй уже собранное. Продолжай с точки остановки.
3. В конце — обнови (не перезапиши) существующий документ новыми находками.
4. Если исследование завершено — обнови research_type, confidence и expires в frontmatter.