Zotero Obsidian Bridge

Bridge Zotero as the literature source of truth with Obsidian as the durable project knowledge base.

Use this skill when the user wants to:

• collect and organize papers in Zotero,
• read papers from Zotero MCP,
• create or update one detailed paper note per paper under Obsidian

  Papers/

  ,
• synthesize those notes into

  Knowledge/

  notes,
• verify that a whole Zotero collection has complete canonical note coverage,
• visualize the literature structure as a default Obsidian canvas.

Core stance

• Zotero owns collection, metadata, attachments, PDF full text, annotations.
• Obsidian owns durable reading notes, project-facing literature knowledge, cross-note links, synthesis.
• Prefer one canonical paper note per paper.
• Prefer filesystem-first Obsidian notes; do not require Obsidian MCP.
• Use this as an explicit, agent-first skill for Zotero ingestion.
• Prefer

  Papers/

  +

  Knowledge/

  as the default bridge targets.
• Prefer

  Maps/literature.canvas

  as the default graph artifact.
• Prefer a strong review schema inside each canonical paper note:

  • Claim

  • Method

  • Evidence

  • Limitation

  • Direct relevance to repo

  • Relation to other papers

• Treat some Zotero

  webpage

  items as valid literature sources when they still expose useful metadata, attachment text, or fulltext.

Default workflow

1. Resolve the current project via

   $obsidian-project-memory

   .
   • If the repo is already bound, use the existing vault.
   • If it looks like a research repo but is not bound, bootstrap it first.
2. Read Zotero items from the target collection/query.
   • If the user asked for a full collection pass, prefer full coverage over a small representative subset.
   • If the transport path through MCP is failing but a local

     zotero-mcp

     source checkout or Python environment is available, use that local fallback to read metadata/fulltext instead of stopping the workflow.
3. For each paper:
   • get metadata,
   • get full text when available,
   • get annotations/notes when helpful,
   • create or update the canonical paper note in

     Papers/

     .
4. Add project-facing structure to each paper note:
   • claim,
   • research question,
   • method,
   • evidence,
   • strengths,
   • limitation,
   • direct relevance to repo,
   • relation to other papers,
   • links to related papers and the best matching

     Knowledge/

     notes.
5. Synthesize the batch into durable

   Knowledge/

   notes such as:

   • Knowledge/Literature-Overview.md

   • Knowledge/Method-Families.md

   • Knowledge/Research-Gaps.md

     only when the synthesis is stable enough to deserve a canonical note.
6. If the request is collection-scoped, update a durable inventory note that records:
   • collection size,
   • item triage,
   • item -> canonical note mapping,
   • current coverage count such as

     16 / 16

     .
   • use the canonical inventory path

     Knowledge/Zotero-Collection-{collection-slug}-Inventory.md

     .
7. Refresh

   Maps/literature.canvas

   .
   • Prefer semantic filtering and edge thinning.
   • Prefer argument-map structure (

     paper + claim + method + gap

     ) over dense all-to-all paper links.
   • If needed, keep a second lightweight display canvas such as

     Maps/literature-main.canvas

     .
8. If the user also wants writing deliverables, update:

   • Writing/literature-review.md

   • Writing/comparison-matrix.md

9. Update today's

   Daily/

   note and repo-local project memory.
10. Run a deterministic verification pass after batch ingestion or schema refactors.

Default outputs

• Papers/*.md

  - one detailed reading note per paper

• Knowledge/*.md

  - durable literature synthesis notes when the batch yields stable knowledge

• Knowledge/Zotero-Collection-{collection-slug}-Inventory.md

  - when the source is a concrete Zotero collection and coverage tracking matters

• Maps/literature.canvas

  - default visual literature graph

• Maps/literature-main.canvas

  - optional lightweight presentation graph after semantic filtering

• Writing/literature-review.md

  - when the user asks for synthesis

• Writing/comparison-matrix.md

  - when cross-paper comparison is useful

Safety rules

• Do not dump raw full text into Obsidian.
• Do not create a new note if the canonical paper note already exists.
• Do not create

  Concepts/

  or

  Datasets/

  trees by default.
• Do not treat

  Experiments/

  ,

  Results/

  , or

  Writing/

  as the default bridge target during Zotero ingestion.
• Do not force every relationship into a new note; use frontmatter fields, sections, wikilinks, and

  linked_knowledge

  first.
• If a relationship is uncertain, record it in the note body or

  Daily/

  instead of manufacturing durable structure.
• Do not stop at a representative subset if the user explicitly asked to check all papers in a collection.
• Do not leave schema drift unresolved across notes in the same collection after a batch pass.

References

Load only what is needed:

• references/WORKFLOW.md

  - end-to-end Zotero -> Obsidian procedure

• references/PAPER-NOTE-SCHEMA.md

  - detailed paper note fields and sections

• references/COLLECTION-INVENTORY-SCHEMA.md

  - canonical inventory note naming and mapping contract

• references/LOCAL-ZOTERO-FALLBACK.md

  - local fallback runbook when MCP transport fails

• examples/example-collection-inventory.md

  - example inventory note

• scripts/verify_paper_notes.py

  - deterministic schema, zotero-key, and inventory consistency check

• ../obsidian-literature-workflow/references/PAPER-NOTE-SCHEMA.md

  - shared note schema

• ../obsidian-literature-workflow/references/CANVAS-WORKFLOW.md

  - default literature canvas refresh rules