zotero-notes
The `/zotero-notes` command batch imports papers from a specified Zotero collection and generates or updates structured reading notes, preferably storing them in an Obsidian vault's `Sources/Papers/` directory or falling back to a markdown file in the working directory. Use this command to systematically convert Zotero library items into detailed research notes with standardized sections including claims, methods, evidence, strengths, limitations, and cross-references to other knowledge within a research project.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/Galaxy-Dawn/claude-scholar/HEAD/commands/zotero-notes.md -o ~/.claude/commands/zotero-notes.mdzotero-notes.md
# /zotero-notes - Zotero to Obsidian Reading Notes
Read papers from the Zotero collection "$collection" and create or update detailed reading notes.
## Default target
- **Preferred target**: the bound Obsidian project knowledge base (`Sources/Papers/*.md`)
- **Fallback target**: `reading-notes-{collection}.md` in the working directory if the current repo is not bound to Obsidian
## Workflow
### Step 0: Resolve whether the current repo is Obsidian-bound
1. If `.claude/project-memory/registry.yaml` exists for the current repo, treat the bound vault as the primary output target.
2. If the repo is a research project but not yet bound, bootstrap it first.
3. If there is no bound project context, fall back to a plain markdown output in the working directory.
4. Treat this command as an explicit agent-first ingestion pass under `$zotero-obsidian-bridge`.
### Step 1: Load papers from Zotero
1. Call `mcp__zotero__zotero_get_collections` to find the matching collection.
2. Call `mcp__zotero__zotero_get_collection_items` to list the papers.
3. For each item, call:
- `mcp__zotero__zotero_get_item_metadata`
- `mcp__zotero__zotero_get_item_fulltext` when a PDF is available
- `mcp__zotero__zotero_get_annotations` when helpful
- `mcp__zotero__zotero_get_notes` when helpful
4. If MCP transport fails but a local `zotero-mcp` checkout is available, use the local Python fallback instead of stopping the pass.
5. Treat Zotero `webpage` items as weak-source inputs unless they clearly expose full paper metadata and useful full text. Abstract-only or placeholder pages must stay `To-Read` and cannot support `Knowledge` or `Writing` claims.
### Step 2: Create/update the canonical paper note
If the project is Obsidian-bound, create or update one canonical note per paper under `Sources/Papers/`.
Each detailed note should contain:
- `Claim`
- `Research question`
- `Method`
- `Evidence`
- `Strengths`
- `Limitation`
- `Direct relevance to repo`
- `Relation to other papers`
- `Knowledge links`
- `Optional downstream hooks`
- canonical `Evidence Record` with `Source type` and `Claim strength` when the paper has reusable claims
Recommended frontmatter fields:
- `title`, `authors`, `year`, `venue`, `doi`, `url`, `citekey`, `zotero_key`
- `keywords`, `concepts`, `methods`
- `related_papers`, `linked_knowledge`, `argument_claims`, `argument_methods`, `argument_gaps`, `paper_relationships`
Prefer updating the existing note over creating a sibling note.
### Step 3: Collection coverage and synthesis
After the paper-note pass:
- update a collection inventory note when the source is a named collection
- record item -> canonical note mapping and coverage counts such as `16 / 16`
- verify coverage against expected Zotero keys, DOI values, or arXiv IDs when the user supplied them
- label abstract-only and webpage-placeholder items separately in the inventory
- synthesize durable literature knowledge under `Knowledge/`, for example:
- `Knowledge/Literature Overview.md`
- `Knowledge/Method Taxonomy.md`
- `Knowledge/Research Gaps.md`
Prefer updating existing canonical knowledge notes over creating parallel summaries.
### Step 4: Refresh the default literature canvas
After batch note creation or substantial note updates, refresh:
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/obsidian-literature-workflow/scripts/build_literature_canvas.py" --cwd "$PWD"
```
This rebuilds `Maps/literature.canvas` from paper-note and knowledge-note links.
### Step 5: Optional synthesis outputs
- If `format=comparison` and promoted claims pass the evidence gate, also update `Writing/comparison-matrix.md`.
- If the paper batch already supports a thematic synthesis and promoted claims pass the evidence gate, update `Writing/related-work-draft.md`.
If not, write only a coverage warning or claim map.
### Step 6: Minimal write-back
Always update:
- today's `Daily/YYYY-MM-DD.md`
- repo-local binding summary when project state changes
### Step 7: Final response
Include:
- collection size and coverage summary
- created / updated note paths
- optional `obsidian://open` links
- optional `obsidian open ...` suggestions when CLI is available
## Fallback behavior
If the repo is not bound to Obsidian:
- create `reading-notes-{collection}.md`
- if `format=comparison` and promoted claims pass the evidence gate, also create `comparison-matrix.md`
## Notes
- Zotero remains the source of truth for collection structure, metadata, attachments, PDF full text, and annotations.
- Obsidian remains the durable project knowledge surface for reading notes, project relevance, and cross-note linking.
- Default bridge targets are `Sources/Papers/` and `Knowledge/`.
- Do not dump raw full text into Obsidian paper notes.
- Do not create `Concepts/` or `Datasets/` trees by default.
- Refresh `Maps/literature.canvas` by default after a substantial Zotero ingestion pass.
- Treat `Experiments/` and `Results/` as later project workflows, not the default Zotero-import destination.
- Do not let abstract-only or webpage-placeholder items support durable claims.Use when creating or configuring Claude Code agents and their frontmatter.
Run a blocker-first post-experiment workflow: validate evidence, produce strict statistical analysis when possible, and generate a decision-oriented results report only when the analysis bundle is sufficient. Uses results-analysis + results-report as a gated two-stage workflow.
Use only when creating new registrable ML components that require Factory or Registry patterns.
This skill should be used when the user asks to "debug this", "fix this error", "investigate this bug", "troubleshoot this issue", "find the problem", "something is broken", "this isn't working", "why is this failing", or reports errors/exceptions/bugs. Provides systematic debugging workflow and common error patterns.
This skill provides reference guidance for citation verification in academic writing. Use when the user asks about "citation verification best practices", "how to verify references", "preventing fake citations", or needs guidance on citation accuracy. This skill supports ml-paper-writing by providing detailed verification principles and common error patterns.
This skill should be used when the user asks to review a diff or pull request, write review comments, audit code quality, establish review standards, or improve how a team performs code review.
Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code. MUST BE USED for all code changes.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.