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) и построй документ скриптом:

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, остальное — обычные абзацы. После сборки показать пользователю файл и перечислить: сколько ссылок разобрано, у скольких пометка «только аннотация», какие места требуют его проверки.