Skill: paper-search

Общий корпус лаборатории

Этот скилл только предлагает статьи и кладёт карточки на доску: в библиотеку и в общий корпус ничего не попадает. Ввозит их /want-2-read (или /paper-ingest для одной статьи), и именно там стоит обязательный шаг отправки в корпус. Не считать статью добавленной, пока она не появилась в корпусе разделами: доска и библиотека это ещё не то, что видят остальные.

Goal

Сначала проверить колонку «Жду публикацию» и пометить [found] те карточки, у которых появилась публичная версия. Затем просканировать текущую Obsidian-библиотеку, вывести темы из живой структуры папок <направление>/<тема>/literature/ и проектных карточек, найти свежие статьи arXiv за последние 30 дней, записать один обзорный файл в personal/paper-search/ и завести по каждой найденной статье карточку в колонке «Инбокс» доски Reading плагина Operon. Решение принимает владелец, перетаскивая карточку из «Инбокса» в «Очередь»; ingest делает потом /want-2-read. Обзорный файл остаётся: он служит журналом уже виденных arXiv ID, чтобы одни и те же статьи не всплывали в следующих поисках.

Boundaries

• Не использовать захардкоженные темы.
• Не предлагать статьи, которые уже есть в литературе тем, журналах и списке отклонённых personal/paper-search/, живых карточках personal/operon/Reading/ или архиве personal/operon/Archives/.
• Не создавать отдельную папку papers_<date>/.
• Не создавать полные paper notes и не запускать paper-ingest: подтверждение выражается переносом карточки владельцем из «Инбокса» в «Очередь», после чего ingest выполняет /want-2-read.
• Все human-facing описания, статусы и инструкции в обзорном файле писать на русском.
• Не раскладывать статьи по отдельным спискам чтения: единственная очередь это доска Reading в Operon.
• Не запускать paper-ingest самому: этот скилл только кладёт карточки в «Инбокс». Ingest делает /want-2-read по тем карточкам, которые владелец перетащил в «Очередь».
• Не менять status ни у одной карточки. Единственная разрешённая правка чужой колонки это префикс [found] и содержимое разделов у карточек в «Жду публикацию».
• Не молчать про правки доски: каждое изменение статуса, заголовка или колонки проговаривается в чате.

Default Workflow

0. Проверить колонку «Жду публикацию» (всегда первым шагом)

До любого поиска пройти по живым карточкам со status: Reading.Жду публикацию:

VAULT="${OBSIDIAN_VAULT:-$HOME/brainlab}"
rg -l '^status: Reading\.Жду публикацию$' "$VAULT/personal/operon/Reading" -g '*.md'

Для каждой карточки поискать точное название в официальных источниках: arXiv, OpenReview, Crossref/DOI, DBLP, страница венью. Записать paperLastChecked: <сегодня> независимо от исхода.

Если публичной версии по-прежнему нет — обновить только paperLastChecked и, если появились новые детали поиска, дописать одну строку под ## Комментарии. Заголовок не трогать.

Если публичная версия найдена — оформить карточку по протоколу [found] ниже. Статус НЕ менять: этот скилл не делает ingest, поэтому и двигать карточку ему не за что. Перенос в «Очередь» сделает /want-2-read — но только после успешного полного ingest, а не по факту находки. До этого карточка живёт в «Жду публикацию» с пометкой [found].

Протокол [found]

1. Дописать префикс [found] в начало H1 и в taskTitle. Ровно один раз: если префикс уже стоит, не дублировать. Префикс нужен, чтобы на доске было видно, какие карточки ждать больше не надо.
2. Записать канонический URL в раздел ## arXiv.
3. Проставить во frontmatter paperSource (arxiv | openreview | doi | venue), paperAvailability: public, paperLastChecked.
4. Удалить устаревший агентский отчёт о том, что статья не находится. Это единственный текст, который скиллу можно стирать в ## Комментарии: собственные заметки владельца не трогать никогда. Вместо отчёта поставить callout находки.
5. Если старая заметка в <направление>/<тема>/literature/ создавалась без доступного full text, оставить paperIngestState: pending во frontmatter, чтобы /want-2-read сделал повторный полный ingest.

Итоговый вид карточки:

---
operonId: <7 символов>
taskTitle: '[found] <Заголовок статьи>'
status: Reading.Жду публикацию
priority: C
datetimeCreated: <ISO>
datetimeModified: <ISO, обновить>
paperSource: arxiv
paperAvailability: public
paperLastChecked: <YYYY-MM-DD>
---
# [found] <Заголовок статьи>

## Заметка

## arXiv
https://arxiv.org/abs/<ARXIV_ID>

## Тема
<тема>

## Комментарии
> [!success] Публичная версия нашлась DD-MM-YYYY
> Источник: arXiv `<ARXIV_ID>`, PDF доступен — https://arxiv.org/abs/<ARXIV_ID>
> Следующий `/want-2-read` сделает полный ingest и после него перенесёт карточку в «Очередь».

Если arXiv-версии не существует, а найден только OpenReview, DOI или страница венью:

## Комментарии
> [!success] Публичная версия нашлась DD-MM-YYYY
> Источник: OpenReview, ICML 2026 — https://openreview.net/forum?id=<ID>
> arXiv-версии не существует, поэтому `/want-2-read` не сможет зеркалить карточку на AlphaXiv:
> MCP умеет добавлять только arXiv-статьи. Ingest в Zotero и Obsidian при этом отработает.

Раздел ## arXiv при этом сохраняет своё имя (менять схему карточки нельзя), но содержит канонический не-arXiv URL и строку arXiv-версии не существует.

Сообщить в чат

Про изменения на доске молчать нельзя: владелец должен понимать, что произошло, не открывая Obsidian. После шага 0 написать отдельным блоком, что именно проверено и что изменилось:

Проверил «Жду публикацию» (N карточек):
- [found] <Заголовок> — нашлась arXiv-версия 2605.24956, помечена [found], лежит в «Жду публикацию»
- <Заголовок> — публичной версии по-прежнему нет, обновил только дату проверки
Помеченные [found] следующий /want-2-read заингестит и сам перенесёт в «Очередь».

Если ничего не изменилось, всё равно написать одну строку: «Проверил «Жду публикацию»: N карточек, изменений нет.» То же правило действует для любого другого случая, когда скилл трогает статус, заголовок или колонку карточки: каждое такое изменение проговаривается в чате отдельной строкой.

1. Построить topic index из библиотеки

Работать от текущей структуры:

# Разборы лежат по темам: один репозиторий `literature` на тему дерева.
LIT=("${OBSIDIAN_VAULT:-$HOME/brainlab}"/*/*/literature)

Извлечь сигналы из:

• папок <направление>/<тема>/literature/
• заголовков заметок
• тегов во frontmatter
• README работ <направление>/<тема>/<работа>/README.md
• уже виденных arXiv ID в литературе тем, в personal/paper-search/, personal/operon/Reading/ и personal/operon/Archives/

Нужно получить ранжированный инвентарь тем:

• доминирующие folder families
• повторяющиеся method keywords
• recurring model families
• application domains

Если библиотека меняется, набор тем тоже должен меняться автоматически.

2. Сформировать несколько topic bundles

Из strongest clusters сформировать несколько независимых поисковых направлений.

Примеры валидных паттернов:

• ключевые слова из названий заметок
• ключевые теги
• пары вроде zeroth-order + llm, lora + hybrid, muon + pretraining

Нельзя:

• подставлять фиксированную тему из памяти модели
• использовать один общий запрос вместо нескольких узких

3. Искать параллельно через subagents

Для повышения полноты нужно запускать параллельных агентов, а не делать один линейный поиск.

Обязательное правило:

• выделить 3-6 topic bundles
• на каждый bundle запустить отдельного subagent через Task
• предпочитать explore для поиска и general для более сложной агрегации
• просить каждый subagent вернуть только релевантные свежие arXiv-кандидаты с кратким обоснованием

Схема примерная, темы берутся из живой структуры, а не отсюда. Прежней двухуровневой таксономии (Optimization/, PEFT/, LLM/) больше нет ни в хранилище, ни в базе, ни на AlphaXiv, ни в Zotero: темы плоские и называются одинаково во всех четырёх местах.

• агент 1: zo-estimators
• агент 2: muon-sign-methods, muon-convergence-theory, markovian-optimization, dro-reweighting
• агент 3: lora-basics, rank-budget, adapter-composition
• агент 4: llm-scaling, training-dynamics, learning-rate-schedules
• при необходимости дополнительные агенты под reinforcement-learning и прикладные темы

Каждый агент должен:

• искать статьи только за последние 30 дней
• исключать already seen arXiv IDs
• возвращать больше кандидатов, чем войдет в финальный shortlist
• отбрасывать weakly related papers сам, но с коротким reason

4. Использовать arXiv через реально доступный путь

Предпочтительный источник: export.arxiv.org.

Если один способ недоступен, агент должен попробовать другой рабочий read-only маршрут, но не должен останавливаться после первой неудачи.

При поиске учитывать только новые статьи за последние 30 дней.

5. Собрать единый shortlist

После параллельного поиска нужно:

• объединить кандидатов от всех subagents
• дедуплицировать по arXiv ID
• отфильтровать уже существующие статьи
• rerank по близости к текущей библиотеке

Ранжирование должно учитывать:

• совпадение с folder names
• совпадение с tags
• совпадение с темами из Papers/, Projects/, Staff/
• близость к уже существующим research clusters

Нужно находить немного больше статей, чем в минимальном shortlist, но не превращать обзор в мусорную свалку. Обычно целевой диапазон: 8-15 хороших кандидатов, если материал реально есть.

6. Записать один overview file в personal/paper-search/

Использовать один файл:

personal/paper-search/papers_DD-MM-YYYY.md

Не создавать папку papers_DD-MM-YYYY/.

Файл служит техническим журналом поиска и dedup по arXiv ID. Пользователь принимает статьи не через редактирование этого файла, а на доске Reading.

Если personal/paper-search/ не существует, создать её.

7. Формат обзора

Обзорный файл должен быть целиком на русском и иметь формат примерно такого вида:

# Новые статьи - DD-MM-YYYY

Найдено N новых статей по M тематическим блокам.

## Откуда взялись темы
- ...

## <Тематический блок из реальной библиотеки>

### [1] Название статьи
**Предлагаемая папка**: `<направление>/<тема>/literature`
**arXiv**: <url>
**Дата**: YYYY-MM-DD

Короткое описание на русском:
- что делает статья
- почему она релевантна текущей библиотеке
- почему предложенная папка подходит лучше всего

Статус: `кандидат, еще не ingested`

## Слабые кандидаты
- Название — краткая причина, почему не вошло в основной список

Важно:

• тематические блоки должны идти из живой структуры библиотеки, а не из захардкоженной онтологии
• у каждой shortlisted статьи должна быть конкретная proposed destination folder
• нумерация должна быть стабильной для аудита и ссылок на кандидатов; решение о чтении принимается переносом карточки на Kanban

8. Сообщение пользователю

После записи обзора сообщать коротко:

Найдено N статей по M темам. Карточки добавлены в Reading → Инбокс.
Перетащи интересные статьи в «Очередь». Технический журнал: [[personal/paper-search/papers_DD-MM-YYYY]]

9. Завести карточки в «Инбоксе» доски Reading

Сразу после записи обзорного файла, без ожидания одобрения: по одной карточке на каждую найденную статью. Владелец разбирает их перетаскиванием, и это дешевле, чем диалог «принять 2, 5, 7».

personal/operon/Reading/<Заголовок статьи>.md

Карточка использует ту же каноническую схему, что и /want-2-read: четыре раздела, ## Заметка пустой до ingest.

---
operonId: <7 символов, уникально: [a-z0-9]>
status: Reading.Инбокс
priority: C
datetimeCreated: <ISO, локальное время>
datetimeModified: <ISO, локальное время>
---
# <Заголовок статьи>

## Заметка

## arXiv
https://arxiv.org/abs/<ARXIV_ID>

## Тема
<человекочитаемая тема из тематического блока обзора>

## Комментарии
<одно-два предложения из обзора: чем статья задевает текущие проекты и почему предложена
именно эта папка>

Правила:

• ## Заметка оставить ПУСТЫМ. Пустой раздел означает «через ingest не проходила», и именно по нему /want-2-read отбирает работу. Не писать туда заглушку.
• Все четыре раздела присутствуют всегда, даже если раздел пуст.
• ## Тема это человекочитаемая метка (LoRA base, Zero-order optimization, Muon), никогда не слаг вроде lora_base и не хвост пути папки.
• operonId должен быть уникален по всей папке personal/operon/Reading/ и по personal/operon/Archives/; проверить перед записью.
• Имя файла всегда personal/operon/Reading/operon-<operonId>.md (правило 11 в ~/.claude/skills/paper-ingest/references/alphaxiv-sync.md), никогда не заголовок статьи и не arXiv ID. Человекочитаемое имя живёт в YAML-поле taskTitle и в H1: Operon показывает taskTitle, а не basename. Заголовок в taskTitle и H1 сохраняется как есть, включая двоеточия и $...$; санитайзить его не надо, потому что в имя файла он больше не попадает. taskTitle при этом обязан быть корректным YAML-скаляром: заключить в одинарные кавычки, внутренний апостроф удвоить.
• Если карточка с такой статьёй уже есть в любой колонке, второй не создавать.
• Статус всегда Reading.Инбокс. Решение о чтении принимает владелец перетаскиванием.

После triage владелец использует две дополнительные колонки:

• Жду публикацию — статья интересна, но публичной версии пока нет. И paper-search (шаг 0), и /want-2-read перепроверяют доступность на каждом запуске и помечают карточку [found], когда публичная версия появилась. Сам paper-search статус не меняет — он не ингестит. [found] карточка попадает в рабочий батч /want-2-read, получает полный ingest и после него переносится в «Очередь»: колонка означает «публичной версии ещё нет», и после разбора это уже неправда.
• _Trash — явный отказ, terminal/cancelled status. Карточка остаётся на доске: ночной архиватор (~/.local/bin/operon_daily_archive.py) выключен 19-10-2026 по просьбе владельца — он уносил «Прочитано» и корзину в personal/operon/Archives, и колонки на доске пустели. Title и arXiv ID остаются частью dedup и в архиве.

Заполнением ## Заметка, **Zotero**: и подробного описания занимается /want-2-read после ingest. Этот скилл ingest не делает и постоянные папки не трогает.

Для отклоненных статей:

• добавить запись в personal/paper-search/rejected.md
• формат должен быть простым и пригодным для future dedup, например:

- 27-04-2026 — Title — https://arxiv.org/abs/2604.12345 — отклонено после daily shortlist

• в обзорном файле papers_DD-MM-YYYY.md перенести их в блок отклоненных или явно пометить как отклоненные

До решения пользователя никаких full notes и никаких Zotero moves.

Hard Rules

• NEVER использовать фиксированные темы вроде EEG, если библиотека этого не показывает.
• ALWAYS писать human-facing обзор по-русски.
• ALWAYS использовать один файл personal/paper-search/papers_DD-MM-YYYY.md.
• NEVER создавать папку papers_DD-MM-YYYY/.
• ALWAYS запускать несколько параллельных subagents для поиска по разным topic bundles.
• NEVER пересказывать пользователю статьи, которые уже есть в библиотеке или были ранее staged/trashed.
• NEVER возвращать статьи, чьи карточки уже лежат в personal/operon/Reading/ или personal/operon/Archives/, включая Reading._Trash.
• ALWAYS заводить по карточке на статью в personal/operon/Reading/ со статусом Reading.Инбокс, пустым разделом ## Заметка и всеми четырьмя каноническими разделами.
• ALWAYS логировать отклоненные статьи в personal/paper-search/rejected.md, чтобы их ID больше не всплывали в shortlist.
• NEVER класть найденное в папку «Want to read» на AlphaXiv. Эта папка означает «владелец решил читать» и синхронизируется с колонкой «Очередь», а paper-search кладёт кандидатов только в «Инбокс». Зеркалить на AlphaXiv будет /want-2-read после ingest.
• BEFORE the owner moves a card to «Очередь», only the dedup overview and the Reading.Инбокс card may exist; no ingest, Zotero item, PDF, or permanent Literature note.
• NEVER выставлять статус карточки выше «Инбокса»: перекладывать в «Очередь» решает владелец, а ingest потом делает /want-2-read.
• NEVER автоматически ставить Жду публикацию или _Trash: это решения владельца на Kanban.
• ALWAYS начинать запуск с шага 0: проверка колонки «Жду публикацию» и протокол [found].
• NEVER двигать карточку из «Жду публикацию» в «Очередь» самому, даже когда публичная версия найдена и бесспорна. Скилл ставит [found] и сообщает; перетаскивает владелец.
• ALWAYS дублировать в чат любое изменение доски: что проверено, что помечено [found], что осталось без изменений. Владелец не должен открывать Obsidian, чтобы понять, что произошло.
• ALWAYS удалять устаревший агентский отчёт «в интернете ничего не найдено» при постановке [found]. Собственный текст владельца в ## Комментарии не трогать никогда.
• ALWAYS сохранять имя файла operon-<operonId>.md и человекочитаемый taskTitle.