Search SOP

Search SOP — 文献搜索标准操作规程

适用场景

Read this skill when the user's request involves any of:

• Searching for academic papers, preprints, or datasets
• Importing references from Zotero, EndNote, BibTeX, or RIS
• Importing a local PDF into the library
• Asking for "最新/latest/recent" papers (recency search)
• Requesting literature from a specific database (CNKI, Google Scholar, WoS, etc.)
• Multi-concept intersection queries (e.g., "PFAS + machine learning")
• Understanding which API tool to use for a specific academic domain

1. Three-Layer Search Architecture

Literature search uses a priority fallback model. Start from Layer 0 for local imports; Layer 1 for search; escalate to Layer 2/3 when the previous layer cannot satisfy the request.

Layer 0 — Local Reference Manager Import (not search)

One-time or periodic import from user's existing reference manager. These are NOT search tools — they read local databases directly.

Zotero fallback chain (try in order):

1. SQLite direct — fastest, works offline, Zotero need not be running
2. Local API (localhost:23119) — Zotero must be running, read-only
3. Web API v3 (api.zotero.org) — needs API Key + User ID, full CRUD
4. Format export — library_export_bibtex/ris → guide user to import manually

EndNote fallback chain: SQLite direct → Format export (no API available).

Docker environment: SQLite and Local API unavailable (host filesystem isolated). Explain to user: use BibTeX/RIS export from source app, or mount host Zotero directory as Docker volume.

Reverse path (RC → Zotero/EndNote): If Zotero Web API Key configured → library_zotero_web_create (requires approval_card). Otherwise → library_export_bibtex + guide user to File > Import in their reference manager.

Other reference managers (Mendeley, ReadCube, JabRef, Citavi, etc.): No direct bridge. Guide user to export BibTeX/RIS → library_import_bibtex/library_import_ris.

Key behaviors: detect → available: false in Docker → explain host isolation, suggest BibTeX/RIS. Reverse write via Web API → approval_card (risk_level: medium). First detection → record in MEMORY.md ## Global > ### Environment.

Layer 1 — Built-in API Tools (free, no auth, structured data)

Always available, require NO API keys. Use as primary search method.

Layer 1.5 — web_fetch Direct Access (relaxed — any public academic URL)

Between L1 API tools and L2 browser, use web_fetch to directly access any publicly accessible academic URL (not limited to known URLs).

Allowed targets (non-exhaustive):

• arXiv RSS (latest by category): https://rss.arxiv.org/rss/{category} (e.g. cs.CV)
• arXiv API (structured): https://export.arxiv.org/api/query?search_query=ti:transformer&sortBy=submittedDate&sortOrder=descending&max_results=20
• Semantic Scholar API: https://api.semanticscholar.org/graph/v1/paper/search
• CORE API: https://api.core.ac.uk/v3/search/works
• OA full-text links — URLs returned by find_oa_version (Unpaywall)
• Author/lab homepages — publication lists, preprint links
• Conference proceedings pages — NeurIPS, ICML, ACL, AAAI proceedings
• Preprint servers — bioRxiv, medRxiv, SSRN landing pages
• PubMed RSS: subscribe URLs from PubMed search results
• Repository metadata — GitHub/GitLab README for research software

RESTRICTIONS (do NOT web_fetch):

• Pages requiring login/authentication
• Paywalled full-text (use find_oa_version first)
• Pages with anti-scraping measures that return empty content

When to use web_fetch: Any public academic URL; page is static HTML or API endpoint; extracting content from a specific page. When to use browser instead: Form interaction needed; JavaScript rendering required; multi-page navigation.

Layer 2 — Browser RPA (databases without public APIs)

When Layer 1 tools cannot reach the required database, use the browser tool.

Target databases: Google Scholar, CNKI / 万方 / 维普, Web of Science / Scopus, IEEE Xplore, ACM DL, SpringerLink, any user-specified database.

CNKI (中国知网) — delegate to the dedicated skills. For any CNKI task, do NOT hand-write browser steps here. Use the purpose-built cnki-* skills instead, which carry verified selectors, captcha/login detection, and single-call extraction: cnki-search / cnki-advanced-search (search), cnki-parse-results, cnki-paper-detail, cnki-journal-search / cnki-journal-index / cnki-journal-toc, cnki-navigate-pages, cnki-download (login required), cnki-export (Zotero). They are the primary path for Chinese-journal retrieval.

IMPORTANT: Never pass profile parameter — omit it to use the default managed browser.

Workflow: open url → snapshot mode=efficient (note targetId) → act kind=type (query) → act kind=click (submit) → snapshot mode=efficient (extract results) → library_add_paper or report → close.

Critical: Always use mode=efficient (~10K chars vs 80K default). Always pass targetId from snapshot into act calls.

Error recovery: "Element not found" → one fresh snapshot, retry once. "Tab not found" → browser action=tabs for active targetIds. Context overflow → extract from last snapshot and close.

Operational limits (revised):

• Max 8 browser snapshots per search session
• Pagination: allowed up to 3 pages of results
• Click into paper detail pages: allowed for extracting abstract, citation count, and metadata
• STILL FORBIDDEN: downloading PDFs, submitting forms, creating accounts, entering personal data (standard GDPR/cookie consent banners may be dismissed with a single click)
• MUST always close browser after search is complete

Layer 3 — API Key Required (optional, user configures)

Do NOT prompt users to register. Only use when the user has already configured.

Third-party keys (Serper, Tavily, etc.): user installs skill/MCP themselves. Never ask users to register for third-party API keys.

2. Domain → Tool Routing

Domain routing below is a STARTING POINT, not a hard constraint. If primary tools return insufficient results, expand to other tools (see §15 Search Iteration Protocol). Do NOT send queries to the wrong domain's tool.

3. Tool Filter Capability Matrix

What each tool CAN filter — determines routing decisions.

4. Sort Parameters Quick Reference

When the user asks for "latest/最新" papers, you MUST pass date-based sort params.

Default sort is relevance for most tools. Never rely on the default when the user wants recent papers.

5. Trigger Word Table

6. Recency Search Protocol

When the user asks for "最新", "latest", "recent", or "past N months/weeks" papers, you MUST override default relevance sorting with date-based sorting.

Recency search workflow:

1. Determine time range: "最新" = last 3 months; "近期" = last 6 months; explicit range if stated.
2. Select 2+ sources by domain (see §2 Domain→Tool Routing).
3. Pass date-based sort and date filter where both are supported (see §4).
4. If API results are insufficient, escalate:
   • web_fetch arXiv RSS feed: https://rss.arxiv.org/rss/{category}
   • browser → Google Scholar with date filter (Tools → Custom range)
5. Never cite web_search / Brave Search unavailability as a reason to stop.

7. Selection Logic Decision Tree

Copy code
0. "latest/最新/recent"? → §6 Recency Protocol. MUST pass date sort.
1. Database NOT in L1 (CNKI, WoS, Scopus, GScholar)? → Layer 2 Browser.
2. Journal name specified? → search_crossref(journal=...) + search_europe_pmc(JOURNAL:...).
   Returns 0? → Layer 2 Browser.
3. Complex multi-filter? → Combine broadest tool + local filtering.
   Still insufficient? → Layer 2 Browser.
4. Simple keyword? → Route by domain (§2). Use 2+ sources for targeted/exhaustive.
5. L1 returns 0? → Suggest broadening keywords + offer L2/web_fetch.
   Do NOT retry same source. Do NOT cite "web_search not configured."
6. Multi-concept intersection? → §8 Decomposition.

8. Multi-Concept Query Decomposition

When the user's topic spans multiple distinct concepts (e.g., "PFAS / microplastics / EDCs + machine learning"), a single combined query returns noisy results because text-based search engines match ANY keyword, not the intersection.

Decomposition strategy:

1. Identify the anchor concept — the methodological or thematic constant (e.g., "machine learning").
2. Split domain-specific concepts into separate sub-queries, each paired with the anchor.
3. Run each sub-query independently on the appropriate L1 tool(s) for the domain.
4. Merge and deduplicate results by DOI / title before presenting.
5. Use filters (from_year, has_abstract: true, sort: "published") on each sub-query.

Anti-patterns:

• Concatenating all keywords into one query string
• Using arXiv for non-CS/physics/math domains just because "machine learning" appears
• Reporting noisy results without filtering — always rate relevance before presenting

9. L1 → L2 Escalation Rules

Use L2 when: user asks for CNKI/WoS/Scopus/Google Scholar, L1 returns 0 for journal query, need paywall fulltext, need faceted search or conference proceedings.

Do NOT use L2 for: simple keyword search (L1 faster), DOI resolution (resolve_doi), citation tracking (get_citations_open).

10. Source Health Awareness

Tool responses include _source_health: { source, latency_ms }.

• Within session: 2+ errors (429/503/timeout) from a source → stop using it, switch to alternative (§2).
• Across sessions: 3+ consecutive sessions with failures → record in MEMORY.md: Source {name} unreliable since {date}: {pattern}. Prefer {alt}.
• Always use at least two sources for targeted/exhaustive scopes.

11. Dynamic Tool Priority

User-configured API keys override defaults by elevating that service to L1:

• Record in MEMORY.md ## Global > ### Environment: "Wentor API: configured", etc.
• MUST-USE rule: User-configured API → call FIRST, then supplement with standard L1. Example: Wentor API configured → wentor_search FIRST, then arXiv/CrossRef.
• Brave API Key → web_search at L1. Zotero API Key → library_zotero_web_*.
• Never store actual API key values — only "configured" status.

12. PDF Import Protocol

"导入PDF / import PDF" workflow:

1. Read the PDF (extract metadata: title, authors, DOI, abstract).
2. Verify via resolve_doi / search_arxiv (match title or DOI).
3. Dedup with library_search (check if already in library).
4. library_add_paper with source: "local_import" + pdf_path.
5. Never fabricate metadata — if extraction fails, ask the user.

13. Post-Search Processing

1. Deduplicate — check DOI / arXiv ID against local library before adding.
2. Rate relevance — high / medium / low. Only add high + medium to library.
3. Batch import — use library_batch_add for 3+ papers.
4. Tag immediately — apply topic tags at import time for future retrieval.

14. Paper Evaluation Criteria

Rate each paper high / medium / low based on: venue quality, citation count (adjusted for age), methodology soundness, reproducibility, and relevance to the user's question. Only add high + medium papers to the library unless user requests otherwise.

15. Search Iteration Protocol

After every search execution, you MUST evaluate results before presenting them to the user. Do NOT treat one-shot search as final.

Evaluation Checklist (执行完每次搜索后必须评估)

1. Quantity: ≥5 relevant papers? If NO → broaden keywords OR switch source
2. Recency: Includes papers from last 2 years? If NO → add date filter
3. Coverage: Different methodologies/schools covered? If NO → cross-source search
4. Key papers: High-citation papers included? If NO → re-search with search_openalex(sort_by='cited_by_count') or search_crossref(sort='cited-by')

Iteration Rules

• Maximum 3 search iterations per topic
• Each iteration: use a different tool OR different keywords (NEVER repeat the same query)
• After each iteration, report a brief summary to the user (what was found, what is still missing)
• If 3 iterations exhausted and still insufficient → inform user and suggest web_fetch (L1.5), Layer 2 browser, or Layer 3 APIs

Cross-Source Search (supplements §2 domain routing)

§2 domain routing is a starting point. When primary results are insufficient:

1. Primary search: Use 1–2 tools from §2 domain routing
2. Supplementary search: If primary results fail the Evaluation Checklist → expand to other L1 tools or web_fetch
3. Merge & dedup: Deduplicate by DOI / title across all sources before presenting

Iteration Decision Flow

Copy code
Search executed
  → Run Evaluation Checklist (4 criteria above)
  → ALL pass? → Present results, DONE
  → ANY fail?
      → Iteration count < 3?
          YES → Refine (different tool / keywords / filters) → re-search → re-evaluate
          NO  → Present best results + inform user of gaps + suggest next steps

RC Local Tools Reference

library_* Call Patterns

search_* → library_* Integration

After search: present paper_card per result → user selects → library_add_paper or library_batch_add → auto task_link if active project → tag with search topic.

Related Research-Plugins Skills

Browse these subcategory indexes for fine-grained methodology skills:

• literature/search/ — Boolean search, arXiv API, Semantic Scholar, citation chains
• literature/metadata/ — DOI resolution, OpenCitations, impact factors
• literature/fulltext/ — Unpaywall, OA strategies, preprint access
• literature/discovery/ — paper recommendation, trend monitoring
• tools/knowledge-graph/ — citation networks, knowledge graph construction
• tools/scraping/ — web scraping for academic sources
• tools/ocr-translate/ — OCR for scanned PDFs, multilingual translation
• domains/ — 16 discipline-specific subcategories (ai-ml, biomedical, chemistry, cs, ecology, economics, education, finance, geoscience, humanities, law, math, pharma, physics, social-science, business). Browse domains/{discipline}/ for domain-specific search strategies and database guides