--- 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_/`. - Не создавать полные 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 из библиотеки Работать от текущей структуры: ```bash VAULT="${OBSIDIAN_VAULT}/Literature" ``` Извлечь сигналы из: - подпапок `Literature///` - заголовков заметок - тегов во 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` Использовать один файл: ```text Literature/_inbox/papers_DD-MM-YYYY.md ``` Не создавать папку `papers_DD-MM-YYYY/`. До одобрения пользователя все хранить прямо в этом `.md`. Если `_inbox/` не существует, создать его. ### 7. Формат обзора Обзорный файл должен быть целиком на русском и иметь формат примерно такого вида: ```markdown # Новые статьи - DD-MM-YYYY Найдено N новых статей по M тематическим блокам. ## Откуда взялись темы - ... ## <Тематический блок из реальной библиотеки> ### [1] Название статьи **Предлагаемая папка**: `Literature//` **arXiv**: **Дата**: YYYY-MM-DD Короткое описание на русском: - что делает статья - почему она релевантна текущей библиотеке - почему предложенная папка подходит лучше всего Статус: `кандидат, еще не ingested` ## Слабые кандидаты - Название — краткая причина, почему не вошло в основной список ``` Важно: - тематические блоки должны идти из живой структуры библиотеки, а не из захардкоженной онтологии - у каждой shortlisted статьи должна быть конкретная proposed destination folder - нумерация должна быть стабильной, чтобы пользователь мог сказать `принять 2, 5, 7` ### 8. Сообщение пользователю После записи обзора сообщать коротко: ```text Найдено 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` - внутри него идут тематические подзаголовки `### ` - каждая статья хранится как один checkbox и человекочитаемый блок строк под ним - первая строка блока содержит только checkbox и заголовок статьи или wiki-link на note, без служебных префиксов вроде `title:` или `note:` - далее идут строки `**Тема**:`, `**Предлагаемая папка**:`, `**arXiv**:`, `**Zotero**:`, `**Дата**:`, `**Краткая идея**:` - если какое-то поле неизвестно, строку все равно сохранить, но оставить значение пустым Для принятой и уже ingest-нутой статьи использовать только такой формат: ```markdown ## Daily_papers_DD-MM-YYYY ### <Тематический блок из overview> - [ ] [[Literature///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, например: ```markdown - 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.