# Research > Проведение качественного исследования с помощью LLM с компенсацией искажений и обязательным сохранением результатов в базу знаний. ОБЯЗАТЕЛЬНО используй этот скилл, когда пользователь просит: провести ресёрч, исследовать тему, собрать best practices, изучить подходы, сделать обзор, сравнить варианты, найти информацию о чём-то, разобраться в теме, «что известно про X», «как устроен Y», «какие есть подходы к Z», «собери информацию», «изучи вопрос». Также используй при любом запросе, который подразумевает сбор и структурирование внешней информации — даже если слово «ресёрч» не произнесено. НЕ используй для простых фактических вопросов с однозначным ответом («какая столица Франции»). - Skill: `dzhokhov/research` (Agent Skill) - Install (CLI): `npx skillmds@latest add dzhokhov/research` - Raw SKILL.md: https://api.skillmd.com/api/skills/dzhokhov/research/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: dzhokhov (https://skillmd.com/u/dzhokhov) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dzhokhov/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-файл 3. Зафиксируй **resolved path** целиком: `<директория>/.md`. Это и есть канонический путь документа для frontmatter, индексации и мультисессионного продолжения. 4. Создай файл с YAML-frontmatter из шаблона Фазы 4 (тело пока пустое) 5. Добавь в TodoList задачу: **«Записать результат в {resolved_path}»** 6. Сообщи пользователю: «Результат буду писать в {resolved_path}» Зачем: файл, созданный до начала работы, гарантирует сохранение. Невозможно «забыть сохранить» то, что уже существует. Результаты дописываются в этот файл по ходу работы, а не копируются туда потом. **Правило:** ресёрч НЕ пишется в `/tasks.md` (это execution queue) и НЕ пишется в `/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. НЕ в чат, НЕ в существующий рабочий артефакт — только в свой файл. ### Структура результата ```markdown --- id: type: note status: active created: updated: aliases: - "<Понятное название на русском>" tags: [knowledge, research, <тематические теги>] source_path: "" 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](../../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 проекта 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.