backup materials and knowledge-base docs

文档润色流和知识库构建流/claude-scholar-upstream/commands/zotero-review.md

@@ -0,0 +1,102 @@
+---
+name: zotero-review
+description: Read and analyze papers from a Zotero collection, then synthesize them into the bound Obsidian project knowledge base or markdown review outputs
+args:
+  - name: collection
+    description: Zotero collection name or keyword to search
+    required: true
+  - name: depth
+    description: Analysis depth (quick/deep)
+    required: false
+    default: deep
+tags: [Research, Zotero, Obsidian, Literature Review, Paper Analysis]
+---
+
+# /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`.