zotero-obsidian-bridge

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.

1. 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.

1. For each paper:

• get metadata,
• get full text when available,
• get annotations/notes when helpful,
• create or update the canonical paper note in Papers/.

1. 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.

1. 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.

1. 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.

1. 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.

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

• Writing/literature-review.md
• Writing/comparison-matrix.md

1. Update today's Daily/ note and repo-local project memory.
2. 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