Paper Reading

Purpose

Use this skill to process a simple Obsidian paper-reading vault. Extend the existing paper-reading behavior; do not introduce RAG, vector databases, background watchers, automatic concept maintenance, or idea generation. Concept work is allowed only when the user explicitly asks for a concept note or concept synthesis.

Expected vault layout:

PaperReading/
├── Inbox/
├── PDFs/
├── Papers/
├── Concepts/
└── Ideas/

Default Behavior

• Treat the current working directory as the vault root when it contains Inbox/, PDFs/, Papers/, Concepts/, and Ideas/.
• When the user manually invokes this skill for the vault, scan Inbox/ for PDF files and process each PDF.
• If the user provides a specific PDF path, process that PDF; if it is inside Inbox/, move it after successful processing.
• Produce note body text in the language requested by the user:
  • Use English when the user says English, 英文, or asks in English without specifying another language.
  • Use Chinese when the user says Chinese, 中文, or asks explicitly for Chinese notes.
  • Default to English when the requested language is unclear.
• Keep Markdown section headings exactly as defined in the template for consistency across the vault.

Vault Workflow

For each PDF:

1. Read the PDF and extract metadata.
   • Extract title, authors, year, venue, arXiv ID, and core paper content.
   • Prefer metadata embedded in the PDF, arXiv identifiers in the file name or first page, and paper text near the title/abstract.
   • If a field is unknown, leave it blank rather than inventing it.
   • Temporary text extraction is allowed, but do not keep txt, extracted.txt, *.extracted.txt, or similar extracted-text files in the vault.
2. Generate a readable file base name from the paper title.
   • Prefer the paper title line as the file base name, preserving spaces, capitalization, and meaningful in-title hyphens.
   • Do not convert spaces to hyphens.
   • Replace filename-unsafe punctuation only when required by the operating system. On Windows, replace : with - and remove or replace \, /, *, ?, ", <, >, and |.
   • Normalize repeated whitespace and trim leading/trailing punctuation.
   • Before writing anything, check for duplicate papers already in the vault by comparing normalized title, arXiv ID, and target Papers/ and PDFs/ paths.
   • If the Inbox PDF is a duplicate of an already processed paper with matching title/arXiv ID and an existing note/PDF, do not create another note and do not store another PDF. Delete only the duplicate Inbox PDF and report that it was skipped as a duplicate.
   • If the title matches but arXiv versions differ, treat it as a versioned duplicate only when the existing note clearly covers the same arXiv ID/version. Otherwise append the arXiv version to the filename, such as (2604.00626v2), to avoid overwriting.
   • If a target file already exists for a different paper, append the year or arXiv ID to avoid overwriting.
3. Move the PDF.
   • Move the processed PDF from Inbox/ to PDFs/<Readable Paper Title>.pdf.
   • After successful processing, no processed PDF should remain in Inbox/.
   • Do not delete PDFs outside Inbox/.
4. Create the paper note.
   • Write Papers/<Readable Paper Title>.md.
   • Use YAML frontmatter followed by the required Markdown sections.
   • Set pdf_path to an Obsidian wikilink such as [[PDFs/<Readable Paper Title>.pdf]] so the PDF is clickable from the note metadata.
   • Do not overwrite an existing note for a different paper. If a note appears to describe the same paper and the same PDF is already stored, treat the Inbox file as a duplicate, delete only that Inbox duplicate, and report it.
   • If a note appears to describe the same paper but the stored PDF is missing, repair the missing PDF link by moving the Inbox PDF into PDFs/ and updating the existing note only when needed.
5. Respect vault boundaries.
   • Concepts/ is read-only during paper Inbox processing. Create or update files in Concepts/ only when the user explicitly asks for a concept note or concept synthesis.
   • Ideas/ is completely user-maintained. Do not create, modify, or delete Idea notes.
   • Do not implement background monitoring, recurring jobs, RAG, vector search, or automatic multi-paper synthesis. Concept synthesis is manual-request only.

Concept Note Workflow

Use this workflow only when the user explicitly asks to create, update, synthesize, or organize a concept note from paper notes. Do not run it for ordinary paper Inbox processing or paper summarization.

For a requested concept such as Self Distillation:

1. Search Papers/ for relevant notes.
   • Search filenames, YAML tags, # Related Concepts, headings, and note body text.
   • Include close spelling and hyphenation variants such as self-distillation, self distillation, and Self-Distillation.
   • Prefer notes with direct conceptual relevance over notes with a single incidental mention.
2. Read all relevant paper notes.
   • Synthesize at the concept level; do not produce a paper-by-paper summary.
   • Identify agreements, disagreements, advantages, limitations, and open problems across the notes.
   • Link related papers using Obsidian wikilinks to paper notes, for example [[Self-Distillation Enables Continual Learning]].
3. Write or update the concept note.
   • Use references/concept-note-template.md.
   • Save to Concepts/<Concept Name>.md.
   • If Concepts/<Concept Name>.md already exists, read it first and update it by merging newly relevant paper-note evidence into the existing structure.
   • Preserve useful existing user-written content where possible; do not replace the whole note with a fresh summary unless the user explicitly asks for a rewrite.
   • Do not create, modify, or delete anything under Ideas/.
4. Keep the output reviewable.
   • Mark uncertainty explicitly.
   • Keep the note concept-centered, not bibliography-centered.
   • Include # Related Papers with wikilinks to the relevant paper notes used.

Note Template

Use references/obsidian-paper-template-en.md for English notes and references/obsidian-paper-template-zh.md for Chinese notes.

Every note must include this YAML frontmatter:

---
title:
authors:
year:
venue:
arxiv_id:
pdf_path:
tags:
---

Use YAML lists for authors and tags when there are multiple values.

Tags

Generate broad, reusable research tags. Prefer 3-8 tags.

Good examples:

• llm
• agent
• safety
• time-series
• distillation
• reasoning
• sft
• rlhf
• rag
• speculative-decoding

Avoid overly narrow tags such as exact model names, dataset split names, one-off benchmark variants, or paper-specific acronyms unless they are genuinely central research areas.

Reading Standards

• Prefer faithful paraphrase over broad claims.
• Separate what the paper says from what the evidence supports.
• In English notes, mark unsupported or weakly supported claims as author claims or insufficient evidence.
• In Chinese notes, mark unsupported or weakly supported claims as 作者声称 or 证据不足.
• Preserve uncertainty when the PDF text, math, tables, or figures are hard to parse.
• Do not invent missing experimental results, citations, venues, arXiv IDs, or implementation details.
• For equations, algorithms, tables, and figures, explain their role and interpretation instead of transcribing every detail.