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`.
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.
Use this agent when the user provides a Kaggle competition URL or asks to learn from Kaggle winning solutions. Examples:
Use this agent when the user asks to "conduct literature review", "search for papers", "analyze research papers", "identify research gaps", "review related work", or mentions starting a research project. This agent integrates with Zotero for automated paper collection, organization, and full-text analysis. Examples:
Use this agent when the user provides a research paper (PDF/DOCX/arXiv link) or asks to learn writing patterns from papers, extract venue-specific writing signals, study paper structure, or mine rebuttal strategies. The agent writes extracted knowledge into the active installed paper-miner writing memory for ml-paper-writing. It does not maintain project-specific writing memory.
Use this agent when the user asks to "write rebuttal", "respond to reviewers", "analyze review comments", or needs help with academic paper review response. This agent specializes in systematic rebuttal writing with professional tone and structured responses.
Test-driven development guide for writing tests first, implementing the smallest passing change, and keeping verification tight. Use when the user explicitly wants TDD or when a task should be driven by failing tests before code.
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.
Commit changes following Conventional Commits format (local only, no push).