Paper Reading

Paper Reading Workflow

Turn a paper URL into a durable, structured note plus an up-to-date global index. This is the standard intake pipeline for this repo's learning log.

Layout

papers/
  INDEX.md              # global categorized index of ALL papers — always update
  TEMPLATE.md           # canonical note template
  notes/
    YYYY-MM-DD-slug.md  # one file per paper

YYYY-MM-DD is the paper's own publication date (not today's date). slug is a kebab-case short name, e.g. 2026-08-19-gen-1.5-one-shot-learners.md.

Step 1 — Fetch the source, faithfully

Do not work from memory or from a single lossy summary. Get the real text.

1. Try WebFetch first for a quick orientation.
2. Then get the raw text so no numbers are lost. Preferred:

   curl -sL -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/125.0 Safari/537.36" "<URL>" -o "$SCRATCH/page.html"
   

   then strip tags to text (drop script/style/svg/noscript, turn block-close tags into newlines, unescape entities) and read the result.
3. arXiv: prefer the https://arxiv.org/abs/<id> page for the abstract, and https://arxiv.org/pdf/<id> (read with the Read tool's pages param) for the full body. ar5iv.labs.arxiv.org/html/<id> is a good HTML fallback.
4. Local PDF: read it with the Read tool using pages ranges.
5. If a section genuinely isn't in the source (common for company blog posts that hide model size or data scale), write "Not disclosed" — never invent it.

Step 2 — Write the note

Copy papers/TEMPLATE.md and fill every section. Rules:

• Quote numbers exactly as the source states them, including error bars (59% (±10% std. dev.)), and say what they are measured over.
• Mark your own commentary clearly. Anything that is your inference rather than the authors' claim goes under Insight & My Take or is prefixed "(my read)".
• Keep the Open Questions and Insight sections opinionated and concrete — they are the part that is worth rereading in six months.
• Record the reference list only when it is short and load-bearing; otherwise list the 5–10 references that actually matter for understanding the work.
• Front-matter of each note is YAML and drives the index:

  ---
  title: ...
  authors: ...
  venue: ...            # arXiv / CoRL 2026 / company blog / ...
  date: YYYY-MM-DD      # publication date
  url: ...
  read_on: YYYY-MM-DD   # the day you read it
  categories: [vla-models, in-context-learning]
  tags: [foundation-model, manipulation]
  rating: ★★★★☆         # subjective importance to the reader's learning path
  status: read          # read | skimmed | to-reread
  ---
  

Step 3 — Update the global index

papers/INDEX.md is the map of the whole library. After every new note:

1. Add a row to the All Papers table (newest first): date, title (relative markdown link to the note), venue, categories, rating.
2. Add the paper under every category section that applies — a paper may appear in more than one. Each entry is one line: link + a one-sentence "why it matters".
3. If no existing category fits, create a new one, and add it to the category legend at the top. Keep categories few and meaningful; prefer merging over proliferating. Current category axes:
   • Foundation models & VLA policies
   • In-context / few-shot learning for control
   • Data engines, scaling laws & pretraining
   • Imitation learning & demonstrations
   • RL for robotics
   • Sim-to-real & simulation
   • Perception, world models & video prediction
   • Dexterous manipulation & hardware
   • Benchmarks, evaluation & datasets
   • Classics & background
4. Bump the counters in the index header (paper count, last-updated date).

Step 4 — Log follow-up Q&A back into the note

Discussion after the first read is often where the real understanding happens — it must not be left in the chat. When the user asks follow-up questions about a paper already in papers/notes/, answer them, then append them to that note's Q&A 精读记录 section (create it as the second-to-last section, just before Citation, if absent). Rules:

• Before answering a "did they disclose X?" question, actually grep the source text — grep -oic hour page.txt is an answer; a recollection is not. Report the search you ran.
• Record the substance, not a verbatim transcript: the question, the source's own words (quoted), and the conclusion.
• Keep the source vs. inference split visible: quote the paper for what it claims, mark your own reasoning as (my read), mark outside field knowledge as such, and write Not disclosed rather than filling gaps.
• Date each round of Q&A.
• If a round surfaces a new paper worth reading, add it to the INDEX reading queue too.

Step 5 — Report back

In the reply to the user, give: the note path, the 3–5 sentence core idea, the headline numbers, and which categories it landed in. Do not paste the whole note.

Conventions

• Note bodies are written in English; keep terminology in the source's own words. The Q&A 精读记录 section follows the language the user asked in (Chinese is fine there) — it is a personal reading log, and translating it loses nuance. Technical terms stay in English inside Chinese prose.
• Never overwrite an existing note silently. If the paper is already in papers/notes/, update that file in place and say so.
• One paper = one file. A blog post series (GEN-0 / GEN-1 / GEN-1.5) = separate files, cross-linked in the Related Work / Lineage section.
• Always commit and push when done — never ask. Every note, index update, and template or skill change gets committed and pushed to origin main in the same turn. See CLAUDE.md. Destructive git operations are the only exception.