paper-search

name	paper-search
description	This skill should be used when the user asks to "найди новые статьи", "поищи свежие статьи по моей теме", "scan for new papers", or wants a library-aware arXiv shortlist written into the Obsidian literature inbox.
version	1.2.0

Skill: paper-search

Goal

Просканировать текущую Obsidian-библиотеку, вывести темы из живой структуры Literature/ и проектных карточек, найти свежие статьи arXiv за последние 30 дней, и записать один обзорный файл в _inbox до явного одобрения пользователя. После решения пользователя принятые статьи должны проходить полный paper-ingest pipeline, попадать в Zotero и Obsidian, а затем записываться в единый reading queue файл Literature/want_2_read.md уже как финальные resolved entries с wiki-link, zotero:// ссылкой и подробным описанием. Отклоненные должны логироваться в _trash, чтобы не resurfacing в будущих поисках.

Boundaries

• Не использовать захардкоженные темы.
• Не предлагать статьи, которые уже есть в библиотеке, _inbox или _trash.
• Не создавать отдельную папку papers_<date>/.
• Не создавать полные paper notes и не запускать paper-ingest до подтверждения пользователя.
• Все human-facing описания, статусы и инструкции в обзорном файле писать на русском.
• Не раскладывать понравившиеся статьи по отдельным спискам чтения; единый reading queue должен жить в Literature/want_2_read.md.
• После подтверждения пользователя нельзя просто переносить shortlist entries в want_2_read.md. Сначала обязателен paper-ingest, потом запись по данным итоговой note.

Default Workflow

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

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

VAULT="/Users/andrey/Library/Mobile Documents/iCloud~md~obsidian/Documents/shkodnik1917/Literature"

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

• подпапок Literature/<top>/<sub>/
• заголовков заметок
• тегов во frontmatter
• проектных карточек в Papers/, Projects/, Staff/
• уже виденных arXiv ID в библиотеке, _inbox, _trash

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

• доминирующие 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-кандидаты с кратким обоснованием

Рекомендуемая схема:

• агент 1: Optimization/zero-order
• агент 2: Optimization/muon и spectral methods
• агент 3: PEFT/lora_*
• агент 4: LLM/* training dynamics, reweighting, scaling
• при необходимости дополнительные агенты для RL или Applied clusters

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

• искать статьи только за последние 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 в _inbox

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

Literature/_inbox/papers_DD-MM-YYYY.md

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

До одобрения пользователя все хранить прямо в этом .md.

Если _inbox/ не существует, создать его.

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

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

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

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

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

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

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

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

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

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

Важно:

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

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

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

Найдено N статей. Обзор: [[Literature/_inbox/papers_DD-MM-YYYY]]

Скажи:
- "принять все"
- "принять 2, 5, 7"
- "отклонить 3"
- или куда именно перенести отдельные статьи

9. Что делать после решения пользователя

Только после одобрения пользователя:

• для каждой принятой статьи запустить paper-ingest
• получить или создать итоговую paper note в подходящей папке литературы
• убедиться, что создан корректный Zotero parent paper item и известны zotero_key и zotero_link
• обновить Literature/want_2_read.md, добавив записи как unchecked чекбоксы под заголовком дня
• внутри дневного блока обязательно сохранить тематическую структуру из papers_DD-MM-YYYY.md, то есть те же тематические секции
• поле Краткая идея брать не из обзорного shortlist, а из итоговой ingest-note, в подробной форме

Canonical format article registry:

• каждый daily block начинается с ## Daily_papers_DD-MM-YYYY
• внутри него идут тематические подзаголовки ### <topic>
• каждая статья хранится как один checkbox и человекочитаемый блок строк под ним
• первая строка блока содержит только checkbox и заголовок статьи или wiki-link на note, без служебных префиксов вроде title: или note:
• далее идут строки **Тема**:, **Предлагаемая папка**:, **arXiv**:, **Zotero**:, **Дата**:, **Краткая идея**:
• если какое-то поле неизвестно, строку все равно сохранить, но оставить значение пустым

Для принятой и уже ingest-нутой статьи использовать только такой формат:

## Daily_papers_DD-MM-YYYY

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

- [ ] [[Literature/<TopLevel>/<Subfolder>/Paper Title]]
  **Тема**: zero-order
  **Предлагаемая папка**: `Literature/Applied/FL` и zero-order
  **arXiv**: https://arxiv.org/abs/ARXIV_ID
  **Zotero**: zotero://select/library/items/ZOTERO_KEY
  **Дата**: YYYY-MM-DD
  **Краткая идея**: Подробное описание статьи на русском, достаточное чтобы понять статью без открытия PDF. Источник этого текста — итоговая Obsidian note после `paper-ingest`.

• если заголовок ## Daily_papers_DD-MM-YYYY уже существует, дописать новые статьи в этот же блок
• если внутри него уже есть нужный тематический подзаголовок, дописать статьи туда, а не создавать дубликат секции
• в обзорном файле papers_DD-MM-YYYY.md отметить такие статьи как принятые и по возможности добавить ссылку на итоговую paper note и Zotero item
• если в строке Предлагаемая папка: указано несколько папок, первая считается canonical destination, а для остальных нужно:
  • в Obsidian создать hard link на ту же .md note
  • в Zotero добавить paper в каждую соответствующую коллекцию

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

• добавить запись в Literature/_trash/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 использовать один файл Literature/_inbox/papers_DD-MM-YYYY.md.
• NEVER создавать папку papers_DD-MM-YYYY/.
• ALWAYS запускать несколько параллельных subagents для поиска по разным topic bundles.
• NEVER пересказывать пользователю статьи, которые уже есть в библиотеке или были ранее staged/trashed.
• ALWAYS добавлять принятые статьи в единый файл Literature/want_2_read.md как красивые multi-line unchecked чекбоксы без технических префиксов в первой строке.
• ALWAYS сохранять внутри daily-блока тематическую структуру из papers_DD-MM-YYYY.md, а не сваливать все статьи в один плоский список.
• ALWAYS логировать отклоненные статьи в Literature/_trash/paper-search_rejected.md, чтобы их ID больше не всплывали в shortlist.
• BEFORE user approval only candidate overview is created.
• AFTER user approval an accepted paper is not complete until paper-ingest finished, the Obsidian note exists, the Zotero parent item exists as a real paper record rather than webpage, the PDF attachment exists, and the want_2_read.md entry contains the parent-item zotero:// link.