cs-paper-deep-notes

name

cs-paper-deep-notes

description

Convert computer science research papers, arXiv PDFs, conference papers, technical reports, paper Markdown, or LaTeX sources into high-fidelity study notes. Use when the user asks to read, understand, deeply summarize, learn from, extract notes from, make Obsidian/Markdown notes for, or prepare a reproduction-oriented explanation of CS/AI/ML/systems/PL/security/HCI/database/networking papers, especially when ordinary summaries lose too much information.

CS Paper Deep Notes

Goal

Produce evidence-grounded study notes that help a reader learn the paper, not just remember its abstract. Preserve mechanisms, assumptions, experiments, limitations, and implementation clues.

Core Rules

• Do not start with a polished summary. First build a paper map and identify evidence.
• Keep claims traceable. Attach section, page, figure, table, equation, or quoted phrase evidence whenever possible.
• Separate author claims from model inference. Label inferred explanations as Inference.
• Prefer dense technical reconstruction over broad paraphrase.
• For CS papers, always inspect method, algorithm/system design, experiments, baselines, ablations, datasets, metrics, complexity, and limitations.
• Do not invent missing details. Mark gaps as Not specified in paper or Needs source check.
• If the source is a PDF, use a structured extraction backend before deep reading when practical. Good candidates are MinerU, marker-pdf, Docling, PyMuPDF4LLM, or existing extracted Markdown/LaTeX.

Input Handling

1. Identify the available source: PDF, Markdown, LaTeX, HTML, arXiv link, DOI, repository, or pasted text.
2. If only a PDF is available, extract or request text with structure preserved. Prefer Markdown/JSON with page numbers, headings, figures, tables, equations, captions, and references.
3. If extraction quality is weak, state the risk and continue with a conservative note: use page/section anchors and mark unverified formula/table details.
4. If code or supplementary material is available, inspect it only after the main paper map unless the user specifically asks for implementation notes first.

Workflow

1. Paper Map

Before writing notes, produce a compact map:

• bibliographic identity: title, authors if available, venue/date if available
• research problem and setting
• claimed contributions
• method/system components
• evaluation tasks, datasets, baselines, metrics
• important figures, tables, equations, algorithms
• limitations and open questions
• prerequisite concepts the reader must know

Use this map to plan the deep read. Do not treat it as the final output.

2. Claim-Evidence Ledger

Build a ledger of important claims:

Claim	Evidence anchor	Type	Notes
Main contribution, mechanism, result, or limitation	Section/page/figure/table/equation	author claim / result / inference	caveats

Include negative evidence when important: missing ablations, absent baselines, unclear implementation, or unreported failure cases.

3. CS Deep Read

Read through these lenses. Skip only when clearly irrelevant to the paper type.

• Problem formulation: inputs, outputs, objective, constraints, assumptions.
• Method mechanics: architecture, algorithm, training/inference pipeline, system workflow, data flow, key design choices.
• Formal content: equations, losses, proofs, complexity, invariants, protocols, semantics.
• Empirical design: datasets, splits, metrics, baselines, ablations, hyperparameters, hardware, statistical reliability.
• Results interpretation: what each major table/figure proves, what it does not prove, and whether the evidence supports the claim.
• Implementation/reproduction: dependencies, hidden engineering choices, pseudocode, minimal reproduction plan, likely failure points.
• Related work positioning: what prior methods are being compared against and what gap is actually new.
• Limitations: author-stated limits plus evidence-based limits inferred from missing experiments or assumptions.

4. Teach-Back Reconstruction

Convert the paper into learning artifacts:

• one-sentence thesis
• key idea in plain technical language
• step-by-step method reconstruction
• pseudocode or pipeline sketch when applicable
• concept dependency graph in bullets
• "why this works" causal chain
• "what would break it" failure analysis
• minimal reproduction checklist
• questions to ask in a reading group

5. Coverage Audit

Before finalizing, check coverage:

• Every section has either been summarized, explicitly skipped with reason, or marked extraction-missing.
• Every central figure/table/equation has a role explanation.
• Main claims have evidence anchors.
• Experimental claims include dataset, metric, baseline, and result direction.
• Unclear or unsupported statements are listed as open questions.

If the audit fails, revise the notes before final output.

Output Modes

Default to a deep Markdown note. If the user asks for Obsidian, include YAML frontmatter and stable headings. If the user asks for a quick version, still include evidence anchors and the coverage audit.

For the full note schema, read references/note-schema.md.

Backend Guidance

Use existing tools rather than recreating parsers:

• MinerU or marker-pdf for complex PDFs with formulas, tables, figures, and layout.
• Docling for general document conversion to structured Markdown/JSON.
• PyMuPDF4LLM for lightweight page-aware Markdown extraction.
• paper-qa-style retrieval for evidence-grounded question answering over many papers or long corpora.
• Zotero/Obsidian integrations only when the user explicitly wants library or vault writeback.

The skill's value is the deep-reading protocol. Parsing and retrieval are replaceable components.

Quality Bar

A good output lets the reader answer:

• What exact problem does this paper solve?
• What is the new mechanism, not just the claimed contribution?
• What evidence supports each important claim?
• How would I reimplement or reproduce the core result?
• Which parts are underspecified, weak, or likely not to generalize?

If the note cannot answer these, keep reading and auditing instead of polishing the prose.