Deeppapernote
Turn one paper (DOI, arXiv, PDF, or Zotero item) into a structured, evidence-based deep-reading Markdown note for your vault or workspace.
Overview
DeepPaperNote is an agent skill for the Idea phase that reads one academic or technical paper and writes a high-quality, evidence-based Markdown deep-reading note into an Obsidian vault or your workspace.
Install
npx skills add https://github.com/917dhj/deeppapernote --skill deeppapernoteWhat is this skill?
- Single-paper focus with strict quality bar—no shallow abstract rewrites
- Reconstructs argument: problem, task definition, data, method, results, limits, and why to keep the paper
- Obsidian-style vault output when configured, otherwise Markdown in the workspace
- Figure placeholders and evidence-based analysis for figures and claims
- Top-tier researcher / algorithm-engineer voice aimed at replication, not pop-science
- one paper per invocation
- Obsidian-style vault path when configured
Adoption & trust: 3 installs on skills.sh; 198 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+300% hot-view momentum).
What problem does it solve?
You have a paper link or PDF but only a vague summary—or no durable note that captures method, evidence, and limits for later build decisions.
Who is it for?
Solo builders doing serious literature review who want one vault-quality note per paper with argument reconstruction and figure placeholders.
Skip if: Batch daily reading lists, automatic Zotero library sync, or lightweight abstract-only summaries when you already have approved specs and do not need primary-source depth.
When should I use this skill?
User gives a paper title, DOI, URL, arXiv ID, Zotero item, or local PDF and wants a polished Markdown deep-reading note.
What do I get? / Deliverables
You get a structured Markdown lab-style note you can file in Obsidian or the repo and reuse when scoping prototypes or implementation plans.
- Single structured Markdown deep-reading note
- Figure placeholders aligned to paper claims
Recommended Skills
Journey fit
Paper deep-reading is a core idea-phase activity when you are still mapping problems, methods, and evidence before you commit to a build. Research subphase is where solo builders ingest primary sources; this skill outputs replication-oriented lab notes rather than shallow summaries.
How it compares
Use instead of asking the agent for a one-paragraph summary when you need replication-grade structure and vault-ready Markdown.
Common Questions / FAQ
Who is deeppapernote for?
Indie builders, ML-minded engineers, and researchers who ingest papers one at a time and want Obsidian-style Markdown notes with method and evidence detail, not pop-science blurbs.
When should I use deeppapernote?
During Idea research when you have a DOI, arXiv ID, URL, Zotero item, or PDF and want a deep note before validate or build; also when organizing lit review into a vault before committing to an approach.
Is deeppapernote safe to install?
Review the Security Audits panel on this Prism page and treat paper URLs and local PDF paths as sensitive; the skill may read files and fetch remote sources depending on your agent setup.
SKILL.md
READMESKILL.md - Deeppapernote
# DeepPaperNote Use this skill when the user wants one outcome: - read one paper carefully - generate a high-quality Markdown note - save the note into an Obsidian-style vault when configured, or into the current workspace when no vault is configured Chinese trigger examples: - `给这篇论文生成深度笔记` - `写一篇高质量论文精读笔记` - `把这篇文章整理成 obsidian 笔记` - `读这篇论文并生成 md 笔记` This skill is intentionally narrow: - it handles one paper at a time - it does not update daily reading lists - it does not treat a shallow abstract rewrite as a successful output - it does not split the public entrypoint into separate setup, troubleshooting, or start commands ## Core Standard The finished note must be more than a summary. It should reconstruct the paper's argument: - what problem it solves - how the task is defined - what data or materials it uses - how the method or analysis actually works - what results matter most - what the paper does not prove - why the paper is worth keeping Default writer persona: - a top-tier researcher or algorithm engineer - writing a replication-oriented lab note - not writing a popular-science explanation - assuming the reader can follow Python, PyTorch, training loops, and evaluation logic The note must adapt to the paper type. Use the same base structure, but shift emphasis for AI methods, benchmarks, clinical studies, and humanities or social-science papers. ## Workflow Follow this order: 1. resolve the paper identity 2. collect metadata 3. acquire the best available PDF 4. extract canonical raw source text: `*_raw_sections.jsonl`, `*_source_manifest.json`, and optional derived `*_full_text.md` 5. extract structural indexes and PDF assets 6. plan figure placement 7. build the full figure/table decision table 8. build the manifest synthesis bundle 9. have the model read the bundle plus raw sections and plan the note 10. run grounding lint on the note plan before drafting from it 11. have the model write the note 12. lint the final note — if the lint output contains `passes_style_gate: false`, apply the Style Gate Enforcement rule before advancing to step 13, 14, or 15 13. perform `final_quality_review` after lint passes 14. perform `final_readability_review` after the quality review passes 15. write into Obsidian This is the required workflow for a normal single-paper note request, not a loose suggestion. Unless this skill explicitly marks a stage as optional, required stages must not be silently skipped, reordered into a shortcut, or treated as complete just because a partial artifact already exists. Global no-short-circuit rule: - do not stop after only the early stages and present the workflow as finished - do not treat slowness, inconvenience, or temporary uncertainty as permission to bypass a required stage - do not replace the declared workflow with an improvised shortcut - if a required stage fails, only do one of three things: - retry that stage - enter a fallback that is explicitly allowed by this skill - stop and report which stage is blocked and which downstream required stages remain incomplete - do not describe the whole task as complete while required downstream stages are still pending Completion-language rule: - say `笔记已完成` only when the required workflow is actually complete - say `已生成草稿` when drafting is done but lint, final readability review, or save is still pending - say `已通过校验` only when lint has actually been run and passed - say `已保存到 Obsidian` only when the write step has actually succeeded - do not treat `lint 已通过` as equivalent to `整篇笔记已经润色完成` - if final readability review is still pending, explicitly say the draft passed script lint but has not finished