zotero-review
The /zotero-review command reads papers from a Zotero collection and analyzes them at configurable depth, then synthesizes findings into either a bound Obsidian knowledge base or a markdown review file. Use this when you need to systematically process a collection of research papers, organize them as canonical notes following a structured schema, identify research gaps and method taxonomies, and generate literature review content backed by actual paper evidence.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/Galaxy-Dawn/claude-scholar/HEAD/commands/zotero-review.md -o ~/.claude/commands/zotero-review.mdzotero-review.md
# /zotero-review - Zotero Collection Literature Analysis Read and analyze papers in the Zotero collection "$collection", with analysis depth "$depth". ## Default target - **Preferred target**: the bound Obsidian project knowledge base - **Fallback target**: `related-work-draft.md` in the current working directory ## Workflow ### Step 0: Resolve the project context 1. If the current repo is already bound to an Obsidian project KB, use that project root. 2. If the repo looks like a research project but is not bound yet, bootstrap it first. 3. If there is no project binding, generate the review in the working directory. ### Step 1: Locate and read the Zotero collection 1. Call `mcp__zotero__zotero_get_collections` to find the matching collection. 2. Call `mcp__zotero__zotero_get_collection_items` to get all papers. 3. For each paper: - call `mcp__zotero__zotero_get_item_metadata` with `include_abstract: true` - call `mcp__zotero__zotero_get_item_fulltext` when available - use abstract metadata as fallback when PDF full text is unavailable 4. If MCP transport fails but a local `zotero-mcp` checkout is available, use the local Python fallback instead of aborting. 5. Treat Zotero `webpage` items as weak-source entries unless they clearly expose full paper metadata and useful full text. Abstract-only or placeholder pages can appear in coverage summaries, but cannot support `Knowledge`, `Writing`, manuscript, or rebuttal claims. ### Step 2: Ensure detailed paper notes exist Before high-level synthesis, ensure the collection has durable paper notes. If the project is Obsidian-bound: - create or update `Sources/Papers/*.md` canonical notes first - keep one canonical paper note per paper whenever possible - align notes to the canonical schema (`Claim / Method / Evidence / Limitation / Direct relevance to repo / Relation to other papers`) - update the best matching `Knowledge/` literature synthesis notes - refresh `Maps/literature.canvas` - update a collection inventory note with item -> note mapping and coverage summary If not Obsidian-bound: - create intermediate `paper-notes/*.md` files in the working directory when `depth=deep` ### Step 3: Synthesize across paper notes Create or update: - `Knowledge/Literature Overview.md` - `Knowledge/Method Taxonomy.md` when useful - `Knowledge/Research Gaps.md` when useful - `Writing/related-work-draft.md` only when the user wants writing-facing synthesis and the promoted claims pass the evidence gate - `Writing/comparison-matrix.md` when useful and promoted claims pass the evidence gate The synthesis should include: - thematic grouping - method families - key findings and tensions - research gaps - direct relevance to the current project - explicit links across `Sources/Papers/` and `Knowledge/` - Evidence Record IDs, source type, claim strength, allowed wording, and forbidden stronger wording for claims that may later enter writing or rebuttal If core papers lack full text or Evidence Records, stop at a collection audit / claim map and state what is missing. Do not generate a polished related-work draft from weak notes. ### Step 4: Push downstream only when justified - keep the default review surface in `Sources/Papers/`, `Knowledge/`, and `Maps/literature.canvas` - update `Writing/` only when the user wants a manuscript-facing review or comparison narrative and promoted claims pass the evidence gate - only update `Experiments/` or `Results/` in a later project workflow when the user explicitly wants that handoff ### Step 5: Minimal write-back Always update: - today's `Daily/YYYY-MM-DD.md` - repo-local binding summary when project state changes ### Step 6: Final response Include: - collection size and coverage summary - updated note paths - optional `obsidian://open` links - optional `obsidian open ...` suggestions when CLI is available ## Notes - Prefer the Obsidian-bound project workflow over loose markdown files when available. - Keep `Sources/Papers/` first-class; the review should be grounded in canonical paper notes rather than only one-shot synthesis. - The default graph artifact is `Maps/literature.canvas`.
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.