# Literature Review Researcher

> Используй ВСЕГДА, когда пользователь хочет исследование научной темы по литературным источникам или разбор литературы готовой статьи. Триггеры режима A: "сделай исследование по теме", "обзор литературы по…", "найди/подбери источники к статье", "literature review" — скилл разбивает тему и текст на подтемы (в т.ч. по ссылкам [N]), ищет реальные статьи (web_search + OpenAlex), пишет русские резюме, определяет базы (Scopus / WoS / РИНЦ / ВАК / Белый список — живой проверкой через браузер) и собирает Word-таблицу по подтемам с сортировкой по годам. Триггеры режима B: "разбор литературы статьи", "разбери ссылки статьи", "обнови Разбор литературы" — по статье со списком литературы строится Word-документ, где каждой ссылке [N] отведён раздел: библиография, пометка доступа, места цитирования, содержательный разбор. Отличие от publications-researcher: тот ищет работы конкретного автора в локальных файлах, этот работает со сторонней литературой.

- Skill: `coolsteps/literature-review-researcher` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add coolsteps/literature-review-researcher`
- Raw SKILL.md: https://api.skillmd.com/api/skills/coolsteps/literature-review-researcher/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: coolsteps (https://skillmd.com/u/coolsteps)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/coolsteps/literature-review-researcher

---


# Обзор литературы по научной теме

Скилл работает в двух режимах.

**Режим A — обзор-таблица по теме** (основной пайплайн ниже): находит реальные
статьи по заданной теме, пишет к ним русские резюме, определяет базы цитирования
и раскладывает всё в Word-таблицу, сгруппированную по подтемам.

**Режим B — разбор литературы, включённой в статью** (раздел в конце файла):
по готовой статье со списком литературы строится Word-документ, где каждой ссылке
[N] отведён отдельный раздел с полной библиографией, честной пометкой доступа
к источнику, местами цитирования и содержательным разбором. Эталон формата —
`Разбор_литературы_нейропикировка.docx` проекта fbpick.

Режим выбирается по запросу: «найди/подбери источники по теме» — режим A;
«разбери литературу статьи», «разбор ссылок», «обнови Разбор литературы» — режим B.
Режимы не исключают друг друга: при запуске режима A обязательно спроси
пользователя, нужно ли дополнительно создать файл разбора литературы (режим B) —
см. Шаг 9.

Скилл рассчитан на запуск в **Cowork**, где доступны
`web_search`, `web_fetch` и **Claude in Chrome** (браузер работает авторизованными
сессиями пользователя в Scopus / WoS / eLibrary — это и даёт достоверную проверку
индексации без API-ключей).

## Главный принцип: никаких выдуманных источников

Это самое важное правило, потому что придуманная ссылка обесценивает весь обзор и
хуже, чем меньшее число реальных статей. Поэтому:

- В таблицу попадает **только реальный источник**, найденный в поиске, с проверяемым
  DOI или рабочей веб-ссылкой. Если DOI/ссылку подтвердить не удалось — источник не
  включается.
- Резюме пишется **строго по фактической аннотации или тексту** статьи. Нельзя
  сочинять содержание по названию. Если аннотацию достать не удалось — так и пометь
  («аннотация недоступна, резюме по названию/фрагментам») и не выдавай догадку за факт.
- Про базы цитирования: где нет уверенности — пиши «уточнить», а не угадывай.
  Приписать статье Scopus/WoS наугад — ошибка, которая подрывает доверие ко всей работе.

## Обзор пайплайна

1. Принять тему и текст статьи.
2. Разобрать текст на подтемы (в т.ч. по ссылкам `[N]`).
3. При неясности — уточняющий диалог и подтверждение подтем.
4. Найти источники по каждой подтеме.
5. Верифицировать источники и извлечь аннотации.
6. Написать русское резюме к каждому.
7. Определить базы цитирования (живая проверка через браузер).
8. Собрать Word-таблицу через скрипт `scripts/build_review_table.py`.

---

## Шаг 1. Принять вход

Тема обычно в запросе. Дополнительно попроси у пользователя:

- **Текст статьи** — сам текст (или файл .docx/.pdf), по которому строятся подтемы.
- **Список литературы статьи**, если он есть отдельно — нужен, чтобы сопоставить
  ссылки `[N]` с названиями источников (см. Шаг 2).
- **Окно по годам** — по умолчанию ищем **за все годы**. Если в запросе сказано
  «за последние 5 лет» (или иной период) — ограничить поиск этим окном.

Если текста статьи нет, но тема задана — можно работать только по теме, но предупреди,
что без текста подтемы будут грубее, и предложи прислать текст.

## Шаг 2. Разобрать текст на подтемы

Цель — получить осмысленную структуру подтем, под которую пойдёт поиск. Действуй так:

1. **Смысловое деление.** Раздели текст статьи на содержательные блоки-подтемы
   (по разделам, абзацам, логическим узлам аргументации). Дай каждой короткое ясное
   название на русском.
2. **Ссылки `[N]` — обязательные точки расширения.** Каждая ссылка в квадратных
   скобках в тексте помечает утверждение, опирающееся на источник, — значит, эту тему
   пользователь считает важной и её точно нужно расширить альтернативными источниками.
   Для каждой `[N]`: возьми предложение/контекст вокруг неё как микро-подтему и
   запланируй по ней поиск дополнительных, альтернативных работ (не только той, что
   уже процитирована).
3. **Якоря из списка литературы.** Если есть список литературы, сопоставь `[N]` →
   название источника и используй эти названия как **якоря**: они уточняют формулировку
   подтемы и задают направление поиска (ищем работы рядом с этой темой — свежее,
   альтернативные подходы, обзоры). По умолчанию всё равно ищем «с нуля», а якоря
   служат уточнением, а не единственным источником.
4. Сведи всё в список подтем (обычные смысловые + порождённые ссылками `[N]`),
   убрав дубли.

## Шаг 3. Уточняющий диалог (если нужно)

Если тема слишком общая, многозначная или текста мало — не бросайся искать вслепую.
Покажи пользователю: (а) предполагаемый список подтем, (б) 2–4 варианта направления
поиска для спорных мест — и попроси подтвердить или поправить. Один короткий раунд
уточнений экономит часы поиска не туда. Если тема и подтемы ясны — переходи к поиску
без лишних вопросов.

## Шаг 4. Найти источники

По каждой подтеме/якорю ищи **~5 источников** (это ориентир на подтему, а не жёсткий
лимит; общего потолка нет — при большой статье источников будет много, это нормально).

**Движок поиска (порядок):**
1. `web_search` — широкий первичный поиск по формулировке подтемы (RU и EN запросы).
2. **OpenAlex** — бесплатный каталог 250+ млн работ без ключа: даёт DOI, аннотацию,
   журнал, год, цитируемость, ссылки на open-access. Ищи через `web_search`/`web_fetch`
   по `https://openalex.org` и `https://api.openalex.org/works?search=...` (URL берётся
   из результатов поиска или как открытая страница). Через Claude in Chrome можно
   открыть openalex.org и вести структурированный поиск с фильтром по годам.
3. **Claude in Chrome** — для находок в Google Scholar и, главное, для проверки баз
   (Шаг 7) по аккаунтам пользователя.

**Приоритет источников:**
- Предпочтительны **рецензируемые журналы и монографии**.
- Конференции и препринты допускаются, но помечаются в таблице (тип + цвет строки),
  чтобы читатель видел их статус. Не выдавай препринт за рецензированную статью.

Собирай по каждому кандидату: авторы, название, год, журнал/издание, DOI или ссылка,
тип (журнал/монография/конференция/препринт), аннотация (текст или ссылка на неё).

## Шаг 5. Верифицировать и извлечь аннотации

Для каждого кандидата подтверди, что источник реальный: рабочий DOI
(`https://doi.org/...`) или живая страница издателя/базы. Достань аннотацию (из
OpenAlex, страницы издателя, eLibrary, PubMed и т.п.) — она нужна для честного резюме.
Кандидатов без подтверждаемой ссылки отбрось (см. главный принцип).

## Шаг 6. Написать русское резюме

К каждому источнику — резюме на русском, **2–4 предложения**: о чём работа, ключевой
результат/вывод и чем она релевантна данной подтеме. Строго по аннотации/тексту, без
домыслов. Если язык оригинала не русский — резюме всё равно на русском.

## Шаг 7. Определить базы цитирования

Нужные базы: **Scopus, Web of Science, РИНЦ (eLibrary), ВАК, Белый список**.
Подход — **живая проверка**, а не статические списки (пользователь залогинен в базах,
и браузер точнее любого справочника). Подробный алгоритм — в
`references/database_verification.md`. Кратко:

- Scopus / WoS — проверяй через Claude in Chrome по аккаунтам пользователя (поиск по
  названию или DOI: индексируется ли работа/журнал).
- РИНЦ — через eLibrary (elibrary.ru).
- ВАК и Белый список — на уровне журнала (Перечень ВАК; Белый список RCSI с уровнем).
- Где база не подтверждается — ставь «уточнить». Не угадывай.

Читай `references/database_verification.md` перед этим шагом.

## Шаг 8. Собрать Word-таблицу

Читай `references/citation_gost.md` — там форматы цитирования по ГОСТ 7.0.5-2008,
правило перевода на русский и точная спецификация JSON для скрипта.

Собери данные в JSON (схема — в citation_gost.md) и построй документ скриптом:

```bash
pip install python-docx --break-system-packages   # если ещё не стоит
python scripts/build_review_table.py review_data.json "Обзор_литературы_ТЕМА.docx"
```

Скрипт создаёт **одну таблицу**, сгруппированную по подтемам: перед источниками каждой
подтемы идёт строка-заголовок подтемы; внутри подтемы источники **отсортированы по
годам** (по возрастанию). Колонки: № | Публикация (ГОСТ, рус.) | Год | Резюме (рус.) |
Базы | DOI/ссылка. Конференции и препринты выделены цветом строки и ярлыком типа.

После сборки покажи пользователю итоговый .docx (`present_files` или `SendUserFile` в
Cowork remote) и коротко перечисли: сколько подтем, сколько источников, где стоят метки
«уточнить», чтобы он мог их проверить.

## Шаг 9. Предложить файл разбора литературы

Показав таблицу, обязательно спроси пользователя, нужно ли дополнительно создать
файл «Разбор литературы» — документ режима B, где каждой ссылке отведён раздел
с библиографией, пометкой доступа, местами цитирования и содержательным разбором
(вопрос через AskUserQuestion, если инструмент доступен; иначе обычным текстом).
Уместнее всего он, когда обзор делался под конкретную статью со ссылками [N].
При согласии переходи к пайплайну режима B, переиспользуя уже собранные и
верифицированные данные об источниках (библиография, аннотации, DOI) — заново
их не ищи.

---

## Что делает этот скилл единообразным с publications-researcher

Стили таблицы (синий заголовок, чередование строк, цветовые метки), формат ГОСТ и
принцип «лучше „уточнить“, чем угадать» согласованы с существующим скиллом
publications-researcher — чтобы обзоры и списки трудов выглядели в одном ключе.

---

# Режим B. Разбор литературы, включённой в статью

Задача режима — не найти новые источники, а объяснить уже включённые: показать,
что каждая ссылка [N] статьи прочитана, понята и стоит на своём месте. Результат —
Word-документ «Разбор литературных ссылок статьи о …», по образцу
`Разбор_литературы_нейропикировка.docx` проекта fbpick (D:\ML_FirstBreaks\docs).
Главный принцип тот же, что и в режиме A: никаких выдуманных сведений об
источниках; всё, чего не знаешь, помечается явно.

## Вход

1. **Текст статьи** (актуальная версия!) со списком литературы — .docx/.md/.pdf.
2. Имеющиеся в проекте **полные тексты источников** (PDF в рабочих каталогах) —
   найди их поиском по файлам, прежде чем объявлять «только аннотация».
3. Если разбор уже существует — предыдущая версия документа: обновляй её,
   а не пиши с нуля, и фиксируй, под какую версию статьи выполнено обновление.

## Структура документа

**Преамбула** (2–4 абзаца, без заголовка):
- какой список ссылок разбирается ([1]–[N]) и из какой статьи, с указанием версии
  статьи и даты приведения в соответствие;
- как устроен разбор — каждой ссылке отведён раздел с библиографией, пометкой
  доступа, местами цитирования и содержательным разбором;
- **легенда пометок доступа** (обязательна, дословно та же градация):
  «Полный текст в распоряжении» — текст есть в файлах проекта и прорабатывался;
  «Знакома содержательно по полному тексту» — работа известна модели на уровне
  полного текста, метод и результаты излагаются уверенно;
  «Только аннотация» — полного текста нет, излагается лишь следующее из аннотации
  и выходных данных, без чисел, которых модель не видела; аннотации малознакомых
  свежих работ дополнительно сверяются с открытыми источниками (OpenAlex).

**Группы ссылок** — заголовки 1-го уровня, объединяющие ссылки по смысловым блокам
статьи (контекст объекта, обзоры, методическая линия, инструментарий, отечественные
работы и т.п.). Порядок групп следует логике статьи, внутри группы — по номерам.
Если группа обслуживает один абзац статьи и к теме работы прямо не относится,
это говорится сразу, и её ссылки разбираются короче — по роли в тексте.

**Раздел каждой ссылки** — заголовок 2-го уровня «[N] Авторы. Название», затем
четыре обязательных элемента:
1. **Полное библиографическое описание** — журнал, год, том, страницы, DOI;
   сверено с фактическим списком литературы статьи (не сочинять выходные данные).
2. **Доступ к источнику.** Одна из трёх пометок легенды, с уточнением
   (имя PDF в проекте, открытый доступ, «сверено по OpenAlex»).
3. **Где и как цитируется в статье.** ВСЕ вхождения [N] в тексте, с дословным
   контекстом или близким пересказом формулировки; если вхождений несколько —
   перечислить каждое. Это ядро режима: перед написанием собери карту вхождений
   поиском по тексту статьи (grep по «[N]», учитывая диапазоны [14–16] и
   перечни [4, 5]).
4. **Содержательный разбор** — 2–6 абзацев по весу ссылки: о чём работа и кто
   авторы (научная школа, почему им можно верить); ключевые результаты с числами
   (только теми, что видел); почему ссылка стоит именно там, где стоит, и что она
   документирует; связь с разбираемой статьёй (что заимствовано, что противопоставлено,
   какую дыру закрывает); при необходимости — честные оговорки (самоцитирование,
   отсутствие DOI, спорные места, опечатки в инициалах).

## Требования честности (дополнительно к главному принципу)

- Числа и формулировки результатов источника приводятся только при доступе
  «полный текст» или «знакома содержательно»; при «только аннотации» — ничего
  сверх аннотации, и это проговаривается в тексте разбора.
- Карта цитирований строится по фактическому тексту статьи, а не по памяти:
  число вхождений каждой ссылки должно сходиться с текстом.
- При обновлении под новую версию статьи проверяются: перенумерация ссылок,
  изменение мест цитирования, единицы измерения и числа, структурные изменения
  (что переехало между разделами) — и правятся ВСЕ затронутые разборы, а не только
  новые ссылки.

## Сборка

Документ собирается в .docx (markdown-исходник + сборщик на docx-js или
python-docx в scratchpad; для проекта fbpick готовый образец —
scratchpad/razbor_v2.md + build_razbor.js той сессии). Заголовки групп — Heading 1,
заголовки ссылок — Heading 2, остальное — обычные абзацы. После сборки показать
пользователю файл и перечислить: сколько ссылок разобрано, у скольких пометка
«только аннотация», какие места требуют его проверки.