SuperAPI AI Directory

ljg-paper-river

Writing & research

View repository

Updated 10-16 08:56

About this skill

ljg-paper-connects: reverse-reading method

A paper is not an island. It stands on the shoulders of predecessors, and also treads on their scars. Dig backward to the root, then look forward—how the problem grew, what each person saw that others did not, and how solutions step by step approached the truth.

Core logic

The most common mistake in reading papers: looking only at the one in front of you, without knowing where it came from. The reverse-reading method does the opposite—first find out whom this paper critiques and improves upon, then find whom that paper critiques, recursively for five levels, digging to the source. Then turn around and read forward from the source.

After reading this way, what you gain is not the knowledge of one paper, but an understanding of an entire line of problem evolution.

Format constraints

Org-mode syntax

  • Use *bold*(single asterisk) for bold, forbid **bold**
  • Heading levels start from * and must not skip levels

ASCII Art

All diagrams use pure ASCII characters. Allowed:+ - | / \ > < v ^ * = ~ . : # [ ] ( ) _ , ; ! ' " and spaces. Unicode drawing symbols are forbidden.

Template authority

The output structure is based on references/template.org。

Denote file specification

  • Timestamp:date +%Y%m%dT%H%M%S
  • Readable time:date "+%Y-%m-%d %a %H:%M"
  • Filename:{時間戳}--paper-river-{簡短標題}__paper_river.org
  • Output directory:~/Documents/notes/

Org file header

#+title:      paper-river-{簡短標題}
#+date:       [{YYYY-MM-DD Day HH:MM}]
#+filetags:   :paper:river:
#+identifier: {YYYYMMDDTHHMMSS}
#+source:     {URL 或來源描述}
#+authors:    {目標論文作者}
#+venue:      {發表場所/年份}

Red lines

  1. Problem as the axis — The main thread of the entire article is "how the problem evolved," not "how the papers are arranged." Papers are supporting actors; the problem is the protagonist
  2. Spoken-language test — Would you tell a friend about the development history of a field this way? If not, revise it
  3. Difference as the core — The focus of each paper's explanation is "where it differs from the previous one," not introducing each paper independently
  4. Zero jargon — First ground it in plain language, then mention the terminology in passing
  5. Logic must not break its chain — From the first paper to the last, the causal chain must not break. Readers can feel "that's why they did it this way"
  6. Honesty — If you cannot find five levels, say how many you found. If the relationship between papers is uncertain, say it is uncertain. Do not fabricate citation relationships

Writing principles

  1. Difference-driven narrative — Do not write an independent summary of each paper and then stitch them together. Start each paragraph with "what problem this paper saw in the previous one," letting the difference itself drive the narrative forward
  2. Transformation instead of definition — When explaining the difference between two approaches, continuously transform approach A into approach B. "If you remove X and add Y, you get Z"—ten times more powerful than "the difference between Z and X is..."
  3. Make reasoning explicit — Before each solution appears, first let readers feel the pressure that "it can't be done any other way." Simulate the process of discovery, not report the results of discovery
  4. One diagram is worth a thousand words — Draw a source-tracing map before the evolution narrative, and draw a compressed overview diagram after the narrative. Let readers first have the whole picture before entering details, and return to the whole picture after finishing the details

Execution

1. Obtain the target paper

  • arxiv URL → WebFetch
  • PDF → Read (note the pages argument limit)
  • Paper title → WebSearch to find the full text

Make sure to get: title, authors, abstract, introduction (especially the critique of prior work in related work / introduction).

2. Extract clues of the critique chain

Carefully read the introduction and related work sections of the target paper. Find:

  • Where it explicitly says "prior method X has problem Y"
  • Which paper(s) it claims to have improved upon
  • Who its compared baselines are

From this, pinpoint the core papers that are critiqued/improved upon(usually 1-3 papers; choose the most direct line).

3. Recursive tracing (deep research)

For the core prior papers found in step 2, repeat the same process: whom do they critique? Whom do they improve upon?

Recursion rules:

  • Recurse at most 5 levels (until level 5 or until the foundational paper of the field)
  • At each level, follow only the line most relevant to the problem, without diverging
  • If at some level no clear object of critique can be found, stop there

Use the Research skill (deep research mode) to obtain key information for each level's paper. For each paper, obtain at least: title, authors, year, core problem, core solution, points of critique of prior work.

4. Frontier extension

In the opposite direction: after the target paper, are there new papers that critique/improve upon it?

Also use the Research skill to search for:

  • Follow-up work that cites the target paper
  • The latest progress on the same problem

After finding the 1-3 most relevant follow-up papers, obtain the same information.

5. Construct the evolution line

Organize the results of steps 3 and 4 into a timeline:

[最老] Paper_0 → Paper_1 → ... → [目標論文] → [後續論文]

Label each arrow with: what problem the latter saw in the former.

6. Forward Feynman narrative

Start from the oldest paper and narrate forward. Key: not introducing each paper independently, but linking them along the thread of problem evolution.

For each paper, cover three things (with emphasis on differences):

  1. What specific problem in the prior solution it saw (explain with examples or scenarios)
  2. The core idea of its solution (explain clearly with an analogy)
  3. What new problems this solution left behind (naturally transitioning to the next paper)

7. Draw diagrams

Two diagrams:

  • Tracing map: placed before the evolution narrative, showing the citation/critique relationships between papers
  • Problem-solution overview: placed after the narrative, compressing the entire line onto one screen. Let people see at a glance how this line grew

8. Distill insights

After reading the entire line, answer:

  • What change is really happening behind this evolution line? (Not surface-level technical iteration, but a deeper cognitive shift)
  • Where is it most likely to go next?

9. Pass the red lines + generate files

Scan the red lines one by one. Additional checks:

  • Whether the causal chain is coherent—string together all the "what problem it saw" statements and read them; does the logic hold
  • Whether the differences stand out—is each paper's focus on "how it differs from what came before"

Read references/template.org, and write to according to the Denote specification ~/Documents/notes/。

Acceptance

  • The problem is the protagonist: What you remember after reading is "how the problem evolved," not "which papers there are"
  • Unbroken causality: From the first paper to the last, every turn has a "therefore"
  • Clear differences: Each paper's unique contribution can be stated clearly in one sentence
  • Outsiders can follow: A smart person who does not understand this field can retell this line of evolution after reading
  • The two figures can be understood independently: Without reading the main text, looking only at the figures still captures the gist
  • Honest labeling: Which citation relationships are confirmed and which are inferred are clearly marked