--- name: three-pass-read description: Read papers by Keshav's three-pass method and reach a conclusion you can defend. Run when given papers — PDF, arXiv link, or full text — and asked which of them are worth reading, what one of them actually says, or whether its evidence holds up. --- Keshav's three passes, each ending at a countable bound, with a stop between them so the user steers. The deliverable is one note per paper, answering Q1–Q8. ## Ground rules — every pass - **Full text or stop.** Obtain the paper's full text (PDF, HTML, or plain text) before starting. When you cannot, ask the user for the file and wait: an abstract plus recall is not a paper. - **Source-tag every claim.** Each statement about the paper carries `§4.2`, `Fig. 3`, or `Table 1`. Where the paper is silent, write `Paper does not state`. - **Follow the user's language.** Write prose in the language the user is writing in. Keep technical terms, quoted phrases, source tags, and the structural headings below in their original form, so files stay mergeable across sessions. `` throughout means `-`, where the slug is three to five words from the title, lowercased and hyphenated — `vaswani2017-attention-is-all-you-need`. ## Pass 1 — triage Runs on exactly the papers the user hands over: one or twenty, every one of them. Where you stop short of the full set, name the papers left unread. Check `papers/` first. A paper that already has a note lands in the table as `read → ` and skips the pass. For the rest, read title, abstract, section headings, conclusion, and the reference list. Fill the **five Cs**: *category* (what kind of paper), *context* (which papers it sits beside), *correctness* (do its assumptions hold), *contributions* (what it claims), *clarity* (is it well written). Name at least one related work you recognise from the references. Land a **verdict** per paper — `deep` / `skim` / `drop` — with one sentence of reason. Draft Q1 and Q6. Write `papers/_triage--.md`, where `n` is the next free number for that date: one row per paper — paper, five Cs, verdict, reason. Show the user the table and **stop**. They pick which papers continue. **Done when** every paper handed over is in the table, each with five Cs filled, ≥1 related work named, and a verdict with its reason — or marked `read → `. ## Pass 2 — grasp Per paper the user picked. Read the body and every figure and table; leave proofs for pass 3. Open `papers/.md` on the skeleton below and fill Q1–Q4 and Q6. Walk each main result by name — every figure, every table: what was it meant to show, and did it show that? Whatever you could not follow goes under `## Stuck`, named and located. That section feeds pass 3 and Q8, and it is worth more to the user than a smooth summary. **Done when** every claim in Q2/Q3/Q4/Q6 carries a source tag, and every figure and table in the paper is either walked or listed under `## Stuck`. Then ask whether to run pass 3. ## Pass 3 — depth Virtually re-implement the paper: make the same assumptions the authors made and rebuild the work in your head, then compare your rebuild against the text. What the comparison exposes is the point of this pass — the paper's real innovations, and the assumptions it leans on without ever stating. Fill Q5 and Q7 from what the comparison turned up. Name every implicit assumption you hit under `## Assumptions`, each with the step that needed it. Close by re-reading `## Stuck`: each entry is either resolved in place, or promoted into Q8 for the user. **Done when** Q5 and Q7 are filled, at least one unstated assumption is named under `## Assumptions`, and every `## Stuck` entry is resolved or promoted. ## The note file ``` # · <authors> · <venue year> `<key>` · source: <path or URL> Unconfirmed: <every question still marked — confirm?> ## Q1 … Q8 one section each, in order ## Stuck ## Assumptions ``` Q1, Q5, Q6 and Q7 carry two columns: **Author says** (source-tagged) and **My call** (judgement). Fill *Author says* yourself; for *My call*, offer two or three candidates marked `— confirm?` and put them to the user at the end of the pass that owns the question. Every candidate still marked `— confirm?` is listed on the `Unconfirmed:` line at the top; the user's answer clears it from that line. | | Question | Who fills it | |---|---|---| | Q1 | Take-away message, one sentence | both columns | | Q2 | Motivation — the people problem, the technical problem, and the research question they distil into. Why does the people problem lack a trivial solution? Which prior solutions exist, and where do they fall short? | author only | | Q3 | Proposed solution — hypothesis, idea, design. Why is it believed to work, how is it an improvement, and how is it achieved? | author only | | Q4 | The authors' evaluation — the logic, argument, evidence, artifacts, and experiments offered in support | author only | | Q5 | Your analysis — is it a good idea, which flaws do you see, what is most interesting or contested? Where it has practical stakes: will it work, who wants it, what would it take to ship, and when? | both columns | | Q6 | Contributions — ideas, data structures, algorithms, software, results, experimental technique | both columns | | Q7 | Future directions — the authors', and yours, often driven by the flaws in Q5 | both columns | | Q8 | Follow-up questions the reading leaves open — what you would raise in discussion, and what stayed hard to follow. At least three. | you write these | Q8 is yours to write, drawn from `## Stuck` and from whatever the pass 3 rebuild could not resolve. Label them as your questions, not the user's. A question a web search settles in a minute belongs elsewhere. Onward: `prepare-to-reproduce` turns a note into a build spec, `paper-to-doc` finalises the note into the one worth keeping, and `paper-read-along` walks prose that will not parse.