Obsidian Literature Workflow

Handle the literature sub-workflow inside the filesystem-first Obsidian project knowledge base.

Role in the workflow

This is a supporting skill under

obsidian-project-memory

.

Use it when the user says things like:

• “My papers are in Obsidian”
• “Read papers from Zotero and create notes in the vault”
• “Review the notes under

  Papers/

  ”
• “Generate literature knowledge notes from this project vault”
• “Connect paper notes to project knowledge”
• “Show me the literature structure as a map/graph”
• “Check whether all papers already have detailed notes”

Assumptions

• The project is already bound through

  .claude/project-memory/registry.yaml

  , or can be imported with

  obsidian-project-bootstrap

• Durable paper notes live under

  Papers/

  inside

  Research/{project-slug}/

• Obsidian note writing is done through the filesystem; no Obsidian MCP is required
• Zotero may still be used as the source of metadata/full text; use

  $zotero-obsidian-bridge

  when the source corpus is in Zotero

Default workflow

1. Read bound project memory and locate the vault root.
2. If the source papers are in Zotero, explicitly use

   $zotero-obsidian-bridge

   to pull them into canonical

   Papers/*.md

   notes.
3. Scan

   Papers/

   and adjacent synthesis notes using filesystem tools.
4. Normalize note metadata and structure using

   $obsidian-markdown

   .
   • Prefer the standardized review schema:

     • Claim

     • Method

     • Evidence

     • Limitation

     • Direct relevance to repo

     • Relation to other papers

5. Query narrowly first:
   • read the relevant paper notes,
   • then the linked

     Knowledge/

     notes,
   • and only then open

     Writing/

     if the user asked for a review or comparison deliverable.
6. Prefer updating existing paper notes and literature synthesis notes over creating sibling notes.
7. Default literature synthesis should land in

   Knowledge/

   , not

   Experiments/

   or

   Results/

   :
   • update

     Knowledge/Literature-Overview.md

   • update

     Knowledge/Method-Families.md

   • update

     Knowledge/Research-Gaps.md

     when the synthesis is stable enough to deserve canonical notes.
8. If the source is a named collection and the user cares about completeness, maintain a collection inventory note with explicit coverage mapping.
9. Refresh

   Maps/literature.canvas

   after major paper-note changes or batch note creation.
   • Prefer argument-map structure over dense all-to-all links.
   • Prefer semantic filtering and edge thinning.
   • Create

     Maps/literature-main.canvas

     only when a lightweight presentation graph is needed.
10. Update the daily note and project memory with what changed.

Default outputs

• Papers/

  remains first-class: one durable paper note per paper whenever possible

• Knowledge/

  holds durable literature synthesis notes

• Maps/literature.canvas

  is the default visual graph surface
• literature work should usually produce at least one of:
  • new or updated paper notes,
  • new or updated knowledge notes,
  • literature-canvas refresh,
  • optional writing synthesis when requested

Default stance

Do not assume by default:

• Concepts/

• Datasets/

• .base

  views

The literature workflow may create

Maps/literature.canvas

by default. Other artifacts still require explicit justification.

References

Load only what is needed:

• references/PAPER-NOTE-SCHEMA.md

  - detailed paper-note frontmatter and sections

• references/CANVAS-WORKFLOW.md

  - how and when to refresh

  Maps/literature.canvas