菜单
Use the Records-backed AutoDownload service as autor's external literature acquisition service. Choose this skill when the user needs PubMed retrieval, PMID resolution, or PDF download to support an autor workspace.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | autodownload |
| description | Use the Records-backed AutoDownload service as autor's external literature acquisition service. Choose this skill when the user needs PubMed retrieval, PMID resolution, or PDF download to support an autor workspace. |
When the user expresses any of the following intents, enter this skill first and then decide whether to switch into a more specific workflow:
/mnt/f/Records (F:\Records) checkout, even though the Python package / Windows service may still be named autodownloadIn one sentence:
autor manages the knowledge base and workspaces; the Records service handles PubMed retrieval and PDF downloads.
In autor's WSL workflow, the Records service usually provides download capability from the Windows side, while autor talks to it as a client over the REST API.
In autor integrations, REST calls remain the default interface. Use CLI commands only for debugging, manual verification, or service-side operations.
The Records service's PDF pipeline involves multi-layer source resolution (S3 cache, Unpaywall, OA Sources, Sci-Hub, browser-driven AutoClick). Each stage can take seconds to minutes per paper. A batch of 10–50 papers can easily take 1–10 minutes.
Treat all download-class operations as long-running. Slow responses are normal and should not be treated as automatic failure conditions.
By contrast, GET /health, POST /retrieve, POST /lookup, and POST /resolve are quick metadata calls and should remain the default first step.
Starting from v0.3.0, the Records-backed AutoDownload service provides an async task API that decouples submission from completion. This is the recommended interface for all download operations from autor:
POST /tasks/ → returns a task_id immediatelyGET /tasks/{id} (poll) or GET /tasks/{id}/events (SSE real-time stream)GET /tasks/{id}/artifact → zip of all PDFs (only available after completed)The task API eliminates:
output_dir / Windows path conversionTask states: queued → executing → partial_done → completed / failed / cancelled
Whether the task is:
you must not use “title-only ingest” as the method, and it should not be treated as a fallback path.
The default requirement is always:
That means you must at least complete PDF download and hand the paper into autor's formal processing loop, which inherently requires waiting.
Default conventions:
http://127.0.0.1:8001GET /healthhttp://127.0.0.1:8001/docsF:\Records on Windows (/mnt/f/Records from WSL)./scripts/start.sh inside the autor repositoryBefore starting any acquisition action, confirm that the service is reachable:
curl http://127.0.0.1:8001/health
If you are not in the default environment, also verify:
AUTOR_AUTODOWNLOAD_PORTAUTOR_AUTODOWNLOAD_WIN_DIR| Endpoint | When to use it | Typical request body | Typical response |
|---|---|---|---|
GET /health | Check whether the service is available | none | status, version, pdf_count |
POST /retrieve | You only have a topic and want candidate PMIDs + metadata first, without downloading | {"topic":"...","max_results":30} | pmids, metadata, mesh_terms, query |
POST /lookup | You already have a concrete PubMed Boolean query | {"query":"...","max_results":40} | pmids, titles |
POST /resolve | You already have DOI / title / PMID identifiers and need conversion | {"identifiers":[...],"target":"pmid"} | resolved or results |
| Endpoint | Method | Purpose | Notes |
|---|---|---|---|
/tasks/ | POST | Submit a download/search/fetch task | Returns task_id immediately |
/tasks/ | GET | List all tasks (filter by ?state=) | |
/tasks/{id} | GET | Get task details + per-item progress + PDF count | |
/tasks/{id}/events | GET | SSE real-time event stream | Streams stage progression |
/tasks/{id}/artifact | GET | Download zip of completed PDFs | Only available when state=completed |
/tasks/{id}/cancel | POST | Cancel a running task | |
/tasks/{id}/retry | POST | Retry a failed task | Creates a new linked task |
Task types for POST /tasks/:
| Type | Required params | What it does |
|---|---|---|
download | pmids: [...] | Download PDFs for specific PMIDs |
search | topic: "..." | Full pipeline: retrieve + download |
fetch | keywords: [...] | Send keywords to AutoClick |
| Endpoint | When to use it | Typical request body | Notes |
|---|---|---|---|
POST /download | Download PDFs by PMIDs | {"pmids":[...],"output_dir":"F:/.../data/inbox"} | Requires output_dir (Windows path); blocking |
POST /search | Unified discover + download | {"topic":"...","max_results":30,"output_dir":"F:/..."} | Requires output_dir; blocking |
POST /fetch | Keywords to AutoClick | {"keywords":[...],"output_dir":"F:/..."} | Fallback only; blocking |
Notes:
/tasks/) is the recommended approach for all download operations; it returns immediately and lets you monitor progress/download, /search, /fetch) still work but block the HTTP connection and require output_dirforce_online is still accepted by the API but is mostly a compatibility fieldcurl -X POST http://127.0.0.1:8001/retrieve \
-H "Content-Type: application/json" \
-d '{"topic":"CAR-T sequential therapy","max_results":30}'
curl -X POST http://127.0.0.1:8001/lookup \
-H "Content-Type: application/json" \
-d '{"query":"(sequential CAR-T OR CAR-T retreatment) AND (CD19 OR CD22)","max_results":40}'
curl -X POST http://127.0.0.1:8001/resolve \
-H "Content-Type: application/json" \
-d '{"identifiers":["10.1038/example","Example paper title"],"target":"pmid"}'
curl -X POST http://127.0.0.1:8001/tasks/ \
-H "Content-Type: application/json" \
-d '{"type":"download","pmids":["12345678","23456789"]}'
Response: {"task_id": "a1b2c3d4e5f6", "state": "queued"}
# Poll
curl http://127.0.0.1:8001/tasks/a1b2c3d4e5f6
# Or stream events in real time
curl -N http://127.0.0.1:8001/tasks/a1b2c3d4e5f6/events
curl -o papers.zip http://127.0.0.1:8001/tasks/a1b2c3d4e5f6/artifact
Unzip into the autor inbox and continue the ingest loop.
Recommended default order:
searchtop-citedexploresearch-author/retrieve/lookup/resolvePOST /tasks/ and monitor until completedunzip papers.zip -d /mnt/f/AutoR/data/inbox/
uv run autor pipeline ingest
uv run autor search "<query>" --top 20
uv run autor ws add <workspace> <paper-id-or-doi...>
Note: this “closed loop” means the full PDF-based workflow. It does not accept shortcuts such as “just put the title in the database.”
When the user asks for a full review, large review, or comprehensive review, acquisition must be coverage-first, not “core-papers-first”.
working corpus for ingestion and section mappingcore analytical corpus for the later main argumentIf literature-landscape MCP tools are available in the current environment, use them before download:
estimate_subfield_scopeanalyze_topic_trendsmeasure_review_saturationrank_seminal_papersretrieve_topic_literatureresolve_literature_identifiersget_citation_neighborhoodThis step is not the final search. It is for calibrating how broad the field is and which branches must be covered.
For a full review, do not rely on a single topic string. Build a query matrix across at least:
CAR-T, CAAR-T, CAR-Treg, engineered Treg, CAR-NK, CAR-M, in vivo CAR, allogeneic, iPSCtoxicity, manufacturing, conditioning, persistence, relapse, immune reset, organ remodelingRun metadata retrieval in batches by branch, not only by one umbrella query. Keep the branch label for every candidate record.
Leave coverage traces in the current canonical planning package:
acquisition-log.md: query matrix, branch objectives, candidate counts, download failures, no-full-text records, and ingest statusreference-map.json: each retained or unresolved candidate's citation key, identifiers, corpus layer, section mapping, and full-text statusevidence-ledger.md: final retained/excluded/unresolved evidence roles by citation keysidecars/: raw Records responses, task payloads, artifact manifests, or large candidate ledgersLegacy files such as query-matrix.md, download-report.md, or corpus-ledger.md may be generated only as derived compatibility exports. The canonical trace of coverage is acquisition-log.md plus reference-map.json.
Do not jump straight to POST /tasks/ with type=download in the following cases:
For these tasks, the default should be to stop at /retrieve, /lookup, or /resolve first, make the academic judgment, and only then download.
Downloading the PDFs with the Records service does not mean the task is finished. The standard closed loop also includes:
data/inbox/pipeline ingest to ingest, enrich, and update indexesws add to attach them to the target workspaceworkspace/<name>/No matter which downstream workflow you end up using, leave the user with at least these traceable artifacts:
Adversarial but evidence-bound Reviewer
Plan a literature review before drafting. Build a lean evidence-bound, taste-gated package using references.bib, reference-map.json, review-plan.md, evidence-ledger.md, and table-figure-plan.md.
Draft a fact-grounded, taste-gated review manuscript from an approved lean planning package. Uses references.bib, reference-map.json, review-plan.md, evidence-ledger.md, and table-figure-plan.md; use only after plan is approved.
Understand the autor codebase at a high level. Use when the user asks how to use autor, what built-in skills it has, what features it supports, which workflow to choose, or wants a project overview before using other skills.
Write an exploratory literature review based on papers in an autor workspace. For approved review-article workflows, respect the canonical references.bib / reference-map.json / evidence-ledger contract produced by plan.
High-level orchestrator for iterative review planning and hypothesis evolution. Builds the current autor planning package, triggers targeted acquisition, maintains corpus layers, and stops before writing.