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](../../03_knowledge/task-routing-methodology-2026-04.md)):

• Standalone ресёрч (переживёт любой проект, переиспользуемое знание) → 03_knowledge/
• Ресёрч в контексте проекта, но знание переиспользуемое → 03_knowledge/, а из /context.md ставь ссылку. Не дублируй в папку проекта.
• Ресёрч, тесно привязанный к проекту и не переиспользуемый (например, конкретные цифры по одному клиенту) → /research/
• Если знание меняет вектор проекта (новый вариант решения, пересмотр подхода) — в /plan.md добавляется open question или Contingency ветка со ссылкой на research-файл

1. Зафиксируй resolved path целиком: /.md. Это и есть канонический путь документа для frontmatter, индексации и мультисессионного продолжения.
2. Создай файл с YAML-frontmatter из шаблона Фазы 4 (тело пока пустое)
3. Добавь в TodoList задачу: «Записать результат в {resolved_path}»
4. Сообщи пользователю: «Результат буду писать в {resolved_path}»

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

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

---

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

---
id: 
type: note
status: active
created: 
updated: 
aliases:
  - ""
tags: [knowledge, research, ]
source_path: ""
freshness: seasonal
expires: 
research_type: knowledge | decision
confidence: low | medium | high
---

# 

## Суть

## Детали

### TL;DR

### 

### 

### Альтернативные точки зрения

### Blind spots и ограничения

## Источники

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

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

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

## Следующий шаг

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

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

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

---

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

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

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

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

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

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

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

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

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

1. В чат — только ссылку + 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dzhokhov
• Source: dzhokhov/markdown-agent-vault-ru
• License: MIT

Install and usage instructions live in the source repository linked above.