obsidian-literature-workflow

name	obsidian-literature-workflow
description	Use this skill when the user keeps paper notes inside an Obsidian project knowledge base and wants filesystem-first literature review, explicit agent-first Zotero ingestion, `Papers/` plus `Knowledge/` synthesis, collection-wide normalization, and a default literature canvas without Obsidian MCP.
version	0.5.0

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