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

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.
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.
For each paper:
- get metadata,
- get full text when available,
- get annotations/notes when helpful,
- create or update the canonical paper note in
```
Papers/
```
  .
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.
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.
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
```
  .
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
```
  .

If the user also wants writing deliverables, update:

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

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

zotero-obsidian-bridge

NPX Install

Tags

SKILL.md Content