repo-readme-paper-curator

name

repo-readme-paper-curator

description

Maintain this repository bilingual paper catalog by appending entries from one or multiple arXiv links to README.md and README.zh-CN.md, then synchronizing English and Chinese Quarto website pages under papers/en/*.qmd and papers/zh/*.qmd. Use when the user provides arXiv URLs and wants title/date/English description/Chinese description/paper/project/code/huggingface links organized into the correct bilingual README sections and reflected on the Quarto site for this repository only.

Repo README Paper Curator

Update together: README.md README.zh-CN.md index.qmd papers/en/index.qmd papers/en/*.qmd zh/index.qmd papers/zh/index.qmd papers/zh/*.qmd

Also update _quarto.yml only when a new top-level category creates new English and Chinese category pages that must appear in website navigation.

index.qmd and zh/index.qmd are generated homepage hubs for Papers, Notes, and Blogs. Paper category browsing and recent-paper lists belong in papers/en/index.qmd and papers/zh/index.qmd.

Shared README Stability

README.md and README.zh-CN.md are also modified by the Notes and Blogs generators.

• Preserve generated Notes and Blogs sections and their Contents entries.
• Keep Notes immediately before Blogs in both Contents lists.
• After writing either README, run the complete CI-equivalent validation sequence:

python scripts/check_readme_qmd_sync.py
python scripts/sync_notes.py
python scripts/sync_blog_shares.py
quarto render --no-execute

• If a checker reports drift, run its --write command and restart the full sequence.

Required Output Format

Use this exact English list style in README.md:

- **<Paper Title>** (YYYY.MM) \
  **Description**: <1-2 sentence summary based on abstract> \
  <a href="<arxiv_abs_url>"><img src="assets/icons/arxiv.svg" alt="Paper" width="20"></a>
  <a href="<project_url>"><img src="assets/icons/project.svg" alt="Project" width="20"></a>
  <a href="<github_url>"><img src="assets/icons/github.svg" alt="Code" width="20"></a>
  <a href="<hf_url>">

Use this exact Chinese list style in README.zh-CN.md:

- **<Paper Title>** (YYYY.MM) \
  **描述**: <中文 1-2 句摘要，基于 abstract> \
  <a href="<arxiv_abs_url>"><img src="assets/icons/arxiv.svg" alt="论文" width="20"></a>
  <a href="<project_url>"><img src="assets/icons/project.svg" alt="项目" width="20"></a>
  <a href="<github_url>"><img src="assets/icons/github.svg" alt="代码" width="20"></a>
  <a href="<hf_url>">//" = =>

Rules:

• Keep field order exactly: Paper, Project, Code, Hugging Face.
• Keep matching field order in Chinese: 论文, 项目, 代码, Hugging Face.
• Render every paper resource as the canonical HTML icon link shown above; do not mix in [[Label](URL)], Markdown image links, or empty anchors.
• Use paper.svg only when a Paper / 论文 URL is not an arXiv URL; otherwise use arxiv.svg.
• Use the official paper title as the display title in both README files.
• Use publication month from arXiv as YYYY.MM.
• Keep existing repository style (headings and markdown layout) unchanged.
• Always include English Description and Chinese 描述, generated from the paper abstract.
• Keep descriptions concise, 1-2 sentences, focus on problem and core contribution.
• Always include Paper / 论文.
• Project / Code / Hugging Face are optional. If unavailable, omit those lines instead of writing N/A.

Markdown Layout Rules

• Use 2 spaces indentation for all lines under one paper bullet item.
• Use \ at the end of the title line and Description line for forced line breaks.
• Keep one blank line between two paper bullet items.
• Do not leave trailing spaces at line ends.
• Keep the icon path, localized alt, and width="20" attributes exactly aligned with the resource kind.

LaTeX Usage Rules

• Prefer plain English in Description; use LaTeX only when the formula is central to the contribution.
• Use inline math only: $...$. Do not use display blocks ($$...$$) inside README paper bullets.
• Keep formulas short and readable (ideally one formula per sentence, at most two per description).
• For titles, keep the official arXiv wording. If title text includes math, preserve meaning and render with inline $...$ when possible.
• Normalize source delimiters when needed: convert \(...\) to $...$; avoid raw \[...\] blocks in entries.
• Avoid custom macro systems (\newcommand, \def) in README text because rendering is inconsistent.
• If rendering is risky, rewrite the expression in concise natural language instead of forcing complex LaTeX.

Example:

• **Description**: We optimize $\\mathcal{L}_{\\text{pref}}$ with margin $\\gamma$ to improve reward discrimination. \

How to Fetch and Read arXiv LaTeX

Use this flow when title/abstract parsing is ambiguous, math-heavy, or formatting-sensitive.

1. Start from the canonical abstract page: https://arxiv.org/abs/<id>.
2. Open the TeX Source link on that page (under full-text links). Treat that URL as the source of truth.
3. If source must be fetched directly, use the arXiv source endpoint pattern https://arxiv.org/e-print/<id> as fallback.
4. Detect source package type:

• multi-file paper: usually tar/gzip archive containing .tex, .bib, figures.
• single-file submission: may be a single compressed TeX-like file.

5. Read the source minimally:

• identify the main TeX file (\documentclass, then \begin{document}).
• extract \title{...} and abstract blocks (\begin{abstract}...\end{abstract} or equivalent).
• follow one level of \input{} / \include{} only if title/abstract are externalized.

6. Convert source text to README-ready prose:

• preserve math meaning; simplify macro-heavy notation.
• do not copy long LaTeX fragments; summarize in 1-2 concise English sentences.

Workflow

1. Read current README.md and README.zh-CN.md; identify matching top-level and second-level categories in both languages.
2. Normalize input into a list of arXiv links (single or multiple).
3. For each arXiv link, parse and extract:

• Canonical arXiv abstract URL (https://arxiv.org/abs/<id>).
• Title from the paper metadata (match the official arXiv title).
• Submission date month for YYYY.MM.

4. Generate English Description and Chinese 描述 from abstract (1-2 concise sentences each), following LaTeX Usage Rules and How to Fetch and Read arXiv LaTeX when needed.
5. Resolve Project URL first, then discover missing links from it.
6. Collect companion links in this order:

• Project: official project page (arXiv links first, then author/org pages).
• Code: GitHub repository URL (direct from arXiv/project page/footer/nav/buttons).
• Hugging Face: model/dataset/space URL (from arXiv/project page/footer/nav/buttons).

7. If Code or Hugging Face is missing, crawl the Project page and one hop of internal links likely named resources, links, demo, github, model, weights, download.
8. Choose the best category/subcategory in README.md, then use the matching Chinese category/subcategory in README.zh-CN.md. Prefer existing second-level subcategories before falling back to top-level sections. Create missing paired English/Chinese categories or subcategories when no existing section fits.
9. Insert each entry into both README files under the chosen subcategory when available; otherwise under the chosen top-level section, based on date ordering (newer first).
10. If one of Project / Code / Hugging Face is unavailable after discovery, omit that line and keep only available fields.
11. After all entries are inserted, update English # Contents and Chinese # 目录 once so both directories remain consistent.
12. Regenerate bilingual homepage, paper overview, and paper category Quarto pages from both README files:

python scripts/check_readme_qmd_sync.py --write

13. If a new top-level category was created, add the corresponding papers/en/<category-slug>.qmd and papers/zh/<category-slug>.qmd pages to _quarto.yml render/navigation as needed.
14. Validate bilingual README/QMD sync:

python scripts/check_readme_qmd_sync.py

15. Render the Quarto website when the task includes website validation:

quarto render

Multi-Link Input Rules

• Accept one or multiple arXiv URLs in one request.
• Process links independently, then apply edits in a single README update.
• De-duplicate by canonical arXiv ID before writing.
• If an entry with the same arXiv ID already exists, skip insertion and keep existing record unless user asks to refresh fields.

Category Selection Policy (Repository-Specific)

Prioritize existing sections in this README:

• Attention
• 注意力机制
• LLMs
• 大语言模型
• Multimodal LLMs
• 多模态大模型
• Embeddings
• 嵌入模型
• Training
• 训练
• Reinforcement Learning
• 强化学习
• Agents Application
• 智能体应用
• Vision
• 视觉
• Auto-Prompt
• 自动提示

Core Principle

Do not classify by surface keywords alone. Classify by the paper's primary research contribution in this order:

1. Main task / problem setting
2. Training paradigm or optimization objective
3. Input-output modality
4. System form (agent / workflow / evaluator / tool-use)
5. Model component or architectural focus

Use the section that best matches the paper's central novelty, not just the model it happens to use.

Section Mapping Rules

Attention

Choose Attention when the main contribution is about transformer internals or attention-specific system design, including:

• attention variants or sparse / linear / lightning-style attention
• KV cache, memory compression, routing within attention, long-context attention efficiency
• layer interaction mechanisms that are primarily attention-architecture innovations

Do not use Attention if attention is only one ingredient inside a broader LLM, MLLM, or training paper.

LLMs

Choose LLMs for general language-model papers where the main contribution is about:

• base LLM architecture, pretraining, post-training, scaling, inference, reasoning, coding, or long-context language modeling
• mixture-of-experts, decoder-only model design, multilingual or general-purpose text foundation models

Use this as the default fallback for text-first foundation model work when no more specific section below is a better fit.

Multimodal LLMs

Choose Multimodal LLMs when the core contribution is multimodal understanding or generation, such as:

• vision-language models, image-grounded reasoning, video-language models, audio-language models
• multimodal alignment, perception-reasoning integration, visual grounding, multimodal long-context modeling
• VLM / MLLM capability papers where multimodal reasoning is the main point

Important boundary:

• If the paper is about multimodal agents or VLA models, but the primary novelty is still multimodal perception/reasoning/modeling, keep it in Multimodal LLMs.
• If the primary novelty is RL algorithm design, move it to Reinforcement Learning instead.

Embeddings

Choose Embeddings when the central topic is representation learning for retrieval or semantic matching, including:

• text embeddings, multimodal embeddings, retrieval representations, contrastive representation learning
• embedding training objectives, similarity learning, reranking representations, dense retrieval encoders

Do not use Embeddings for general LLM hidden-state analysis unless the deliverable is an actual embedding model or retrieval representation method.

Training

Choose Training when the core novelty is a general training method rather than a model family or RL method, including:

• supervised fine-tuning methodology
• data selection, curriculum learning, token/sample weighting, distillation, optimization recipes
• training efficiency methods that are not specifically attention-centric and not primarily RL

Use Training especially when the paper proposes a reusable training recipe applicable across multiple model types.

Reinforcement Learning

Choose Reinforcement Learning when the main contribution is policy optimization or reward-driven learning, including:

• RLHF, RLAIF, GRPO, PPO, DPO-like RL variants when framed as RL or online policy improvement
• reward modeling tightly coupled to RL training
• reasoning RL, agent RL, VLA RL, robotic RL post-training, exploration or credit assignment methods

Important boundary:

• A vision-language-action paper is not automatically Multimodal LLMs.
• If its main novelty is RL formulation, reward construction, trajectory optimization, or policy improvement, classify it as Reinforcement Learning.
• If its main novelty is multimodal architecture or perception-reasoning modeling without RL as the central contribution, classify it as Multimodal LLMs.

Agents Application

Choose Agents Application when the paper's main contribution is agent systems or tool-use workflows, including:

• autonomous agents, browser/computer-use agents, tool-using LLM systems
• multi-agent orchestration, planning-execution-reflection workflows, application frameworks
• software agents, web agents, productivity agents, embodied agents at the system/workflow level

Important boundary:

• If the work is mostly an agent application/framework, use Agents Application.
• If it is mostly an agent training or RL method, prefer Reinforcement Learning.
• If it is mostly a foundation model capability paper that includes agent benchmarks, prefer LLMs or Multimodal LLMs.

Auto-Prompt

Choose Auto-Prompt when the main contribution is automatic prompt construction, prompt optimization, evaluator prompt evolution, or prompt ensemble/search.

Decision Procedure

For every paper, explicitly run this decision order before inserting:

1. Is the main novelty an RL / reward / policy optimization method?
   • Yes -> Reinforcement Learning
2. Is the main novelty a general training recipe such as SFT/data selection/distillation/curriculum?
   • Yes -> Training
3. Is the main novelty automatic prompt optimization or judge prompting?
   • Yes -> Auto-Prompt
4. Is the main novelty an agent system / tool-use workflow / orchestration framework?
   • Yes -> Agents Application
5. Is the paper primarily about embedding / retrieval representations?
   • Yes -> Embeddings
6. Is the paper primarily about attention-specific architecture or efficiency?
   • Yes -> Attention
7. Is the paper primarily about multimodal modeling, perception, or multimodal reasoning?
   • Yes -> Multimodal LLMs
8. Otherwise -> LLMs

Subcategory Reuse Policy

After choosing the top-level category, always try to place the paper into the most specific existing second-level subcategory under that category before creating anything new.

Use this subcategory preference order:

1. existing second-level subcategory with clear semantic match
2. newly created second-level subcategory under the chosen top-level category
3. top-level category directly, only if the section intentionally has no subcategory structure

Subcategory matching should use the paper's primary contribution, not lexical overlap alone. Examples:

• a general technical report should prefer LLMs -> Foundation Models
• a visual reasoning paper should prefer Multimodal LLMs -> Vision-Language
• a VLA policy optimization paper should prefer Reinforcement Learning -> VLA RL
• a token weighting SFT paper should prefer Training -> SFT

If a top-level category already contains second-level subcategories, prefer inserting into one of them instead of mixing some papers directly under the top-level heading.

Tie-Breaking Rules

When multiple sections seem plausible, break ties with these priorities:

• training objective beats modality
  • Example: a VLA paper centered on policy optimization -> Reinforcement Learning, not Multimodal LLMs
• system contribution beats benchmark coverage
  • Example: a general LLM paper evaluated on agent tasks -> LLMs, not Agents Application
• core reusable method beats downstream application domain
  • Example: a generic data selection method for LLM post-training -> Training, not the domain it was tested on
• architectural primitive beats generic model family only when the primitive itself is the novelty
  • Example: KV-cache compression method -> Attention; otherwise keep broader papers in LLMs / Multimodal LLMs

Response Requirement for Ambiguous Cases

If classification is ambiguous, briefly state the applied rule in the response, for example:

• "Classified under Reinforcement Learning because the main novelty is the policy optimization method rather than the multimodal architecture."
• "Classified under Training because the paper's main contribution is a general SFT recipe, not a new foundation model."

Quick Reference: Paper Type -> Recommended Placement

Use this quick table as a fast default, then verify with the full decision procedure above.

• base text foundation model / technical report -> LLMs
• MoE LLM / long-context LLM / reasoning LLM / coding LLM -> LLMs
• vision-language model / video-language model / audio-language model -> Multimodal LLMs
• multimodal reasoning / grounding / perception-language integration -> Multimodal LLMs
• VLA model with architecture or perception as the main novelty -> Multimodal LLMs with optional subcategory ## VLA
• VLA model with RL or reward design as the main novelty -> Reinforcement Learning with optional subcategory ## VLA RL
• RLHF / GRPO / PPO / online policy optimization / credit assignment -> Reinforcement Learning
• SFT recipe / data selection / curriculum / distillation / token weighting -> Training
• retrieval encoder / embedding model / reranker representation learning -> Embeddings
• tool-use agent / browser agent / computer-use / multi-agent workflow -> Agents Application
• prompt search / prompt optimization / LLM judge prompt evolution -> Auto-Prompt
• attention variant / KV cache / long-context attention efficiency -> Attention

Suggested Reusable Subcategories

Prefer these names when they fit, to keep the repository taxonomy consistent over time:

• under LLMs: ## Foundation Models, ## Reasoning, ## Coding, ## Long Context, ## MoE, ## Inference
• under Multimodal LLMs: ## Vision-Language, ## Video, ## Audio, ## VLA
• under Reinforcement Learning: ## RLHF, ## Reasoning RL, ## Agent RL, ## VLA RL
• under Agents Application: ## Computer Use, ## Web Agents, ## Multi-Agent, ## Memory
• under Training: ## SFT, ## Data Selection, ## Distillation
• under Embeddings: ## Text Embeddings, ## Multimodal Embeddings, ## Retrieval

Auto Create Category/Subcategory

Creation is allowed by default when existing sections are too coarse or clearly mismatched. Do not force a paper into an existing section if that would make the repository taxonomy less accurate.

When to Create a New Category

Create a new top-level category when all of the following are true:

• no existing top-level section matches the paper's primary contribution well
• placing it into the nearest existing section would be misleading for future browsing
• the new category is likely reusable for future papers, not a one-off label

Examples of valid reasons to create a new top-level category:

• the repository starts accumulating papers on a major area not covered by current sections
• a paper family is repeatedly being misfiled under a too-broad bucket
• the distinction is meaningful at browsing time, such as Reasoning, Inference, Robotics, or Evaluation, if these become recurring themes in the repo

When to Create a New Subcategory

Prefer creating a new second-level subcategory before creating a new top-level category when the paper clearly belongs under a broad existing area but needs finer organization.

Examples:

• under LLMs: ## Reasoning, ## Inference, ## Long Context, ## MoE
• under Multimodal LLMs: ## Vision-Language, ## Video, ## Audio, ## VLA
• under Reinforcement Learning: ## RLHF, ## Reasoning RL, ## VLA RL
• under Agents Application: ## Computer Use, ## Web Agents, ## Multi-Agent

Creation Rules

When creating new categories or subcategories:

• Reuse existing headings when similarity is high; avoid near-duplicate headings.
• Prefer concise names with broad reuse value.
• Prefer noun phrases over long descriptive headings.
• Prefer singular/plural style consistent with nearby sections.
• Create at most one new top-level category for a single paper unless explicitly requested otherwise.
• If a broad section already exists, prefer adding a subcategory under it instead of creating a sibling top-level section.

Placement Rules

• Insert a new top-level category near the most semantically similar existing section; otherwise append at the end.
• Insert a new subcategory under the chosen parent section and keep sibling subcategories semantically grouped.
• Under the new section/subsection, append paper entries using the required list format.

Decision Bias

Use this preference order:

1. existing subcategory
2. new subcategory under an existing top-level category
3. existing top-level category
4. new top-level category

If classification is still fuzzy, prefer creating a reusable subcategory rather than misclassifying the paper into an over-broad bucket.

Contents Update Requirement

Whenever a new top-level category or second-level subcategory is created, update # Contents in the same edit so links stay aligned with the heading structure.

Link Discovery and Validation

Use this source priority:

1. arXiv abstract page metadata and external links
2. official project page
3. official project page one-hop internal links
4. author/org release pages explicitly referenced by 1-3

Validation rules:

• Prefer canonical HTTPS URLs.
• For GitHub, prefer repository root URL over issue/pull/blob paths.
• For Hugging Face, prefer canonical repo root (https://huggingface.co/<org_or_user>/<repo>), dataset, or space root.
• Remove tracking query parameters when possible.
• Deduplicate links; keep one best URL per field.

Editing Constraints

• Modify README.md, README.zh-CN.md, and the synchronized Quarto files generated from them.
• Preserve existing heading hierarchy and qmd card layout.
• Keep the homepage as a three-entry hub for Papers, Notes, and Blogs.
• Keep paper category browsing and recent-paper lists on the generated paper overview pages.
• Keep additions minimal and preserve existing style.
• Do not rewrite unrelated content.
• Do not commit or edit rendered _site/ output.

Contents Hygiene

• Keep # Contents aligned with actual headings in README.
• Keep # 目录 aligned with actual headings in README.zh-CN.md.
• Add new top-level category links when new categories are created.
• Add second-level links in Contents only when the README currently follows that pattern for the same section.
• Remove stale Contents links that no longer have matching headings.
• Keep _quarto.yml navigation aligned with top-level category qmd pages.

Time Ordering Rule

• Treat time as paper attribute in (YYYY.MM).
• Within the same category/subcategory, sort entries by date descending.
• Newer papers must appear above older papers.
• If two papers share the same month, keep existing relative order and place the new one after existing same-month entries.

User-Learned Best Practices & Constraints

Auto-Generated Section: This section is maintained by skill-evolution-manager. Do not edit manually.

User Preferences

• README paper resources must use the repository's canonical HTML icon anchors in both languages; do not mix in text-only Markdown links.

Known Fixes & Workarounds

• Reject empty anchors and restore the matching local icon, localized alt label, and width="20" attributes.
• Keep each paper title and Description/描述 line terminated by a space plus backslash, with a blank line before the next paper.
• Before regenerating Quarto pages, verify English and Chinese paper order, category/subcategory slugs, dates, titles, and resource kind/URL sequences are identical.