nature-downloader

Use when a user needs lawful academic full text, CNKI institutional access, English OA retrieval, publisher API access, institutional browser fallback, or supporting information downloads.

By yuan1z0825 · 7,757 installs

npx skills add yuan1z0825/nature-skills --skill nature-downloader

Source repository · Upstream listing

Nature Literature Downloader This skill routes literature through lawful open access, publisher API, CNKI institutional, and browser based institutional providers. scripts/batch download.mjs is the orchestration entry point; school configuration, publisher credentials, metadata/OA resolution, provider downloads, content validation, and manifests are separate modules. Verified routes are examples, not defaults. Every institution should start from the user's actual library resource URL, because resource portals, CAS callbacks, EZproxy, WebVPN, IP authenticated database pages, and database detail pages reveal the live authorization path more reliably than a school name. SI confirmation gate — do this first. Before downloading any PDF, CAJ, HTML, XML, archive, or attachment, ask whether the user wants Supporting Information. An explicit request for SI counts as yes; an explicit request for正文 only counts as no. Otherwise ask once for the whole batch. Run the downloader with exactly one of si or no si . Without either flag the script returns si confirmation required and does not create the output directory. Main workflow. Normalize the DOI/title and identify language and publisher before routing. Chinese literature always uses CNKI. For English Elsevier, Springer Nature, and IEEE articles with usable provider credentials, try the publisher API first and do not require an OA determination after a successful API download. If that API attempt fails, automatically check legitimate OA sources. Other English publishers check OA first, then use the institutional Web Access route when OA is unavailable. Chinese literature is CNKI only. A Chinese title, zh metadata language, explicit CNKI source URL, or route cnki must use CNKI even if another OA copy appears to exist. Reuse the user's current Chrome library/CNKI login state and prefer configured discovery.cnki url . Never export cookies or collect the institutional password. Publisher API fallback. A valid API key does not guarantee full text entitlement. When an Elsevier, Springer Nature, or IEEE API attempt returns no entitlement or no usable full text, automatically try legitimate OA sources first. Return api fallback confirmation required and ask once whether to use Web Access only after both the publisher API and OA routes fail. Do not switch to institutional Web Access automatically. Browser state principle. Authorized downloads depend on the exact browser profile where the user is logged in. If a proxy, CDP session, or browser automation tool opens a fresh profile or a different browser with no login state, do not treat the failure as missing library permission. Switch to a control path that reuses the user's active browser session, or ask the user to authenticate in the controlled browser instance. Format principle. PDF, HTML full text, and database native formats such as CAJ are different deliverables. If the user asks for PDF only, require a real PDF link or %PDF response and report no authorized pdf found / pdf fetch failed when none exists. Do not save CAJ, HTML, or a login page as if it were a PDF. Download Intake and First Run Configuration For every download request, first establish the paper list and ask: Do metadata lookup before this question only when needed to identify the requested papers. Do not download files until the answer is known. Configure a library only when the selected route is CNKI or Web Access. Configure a publisher API only when the selected English article belongs to Elsevier, Springer Nature, or IEEE; an OA determination is not required before trying a configured provider API. Paid Library Resource Configuration Ask for the library resource URL the user actually uses: Then infer the authorization route from the URL before saving config: The distributed skill contains no school presets. If the user cannot provide a resource URL, ask them to locate their institution's library/database entry instead of guessing a school specific domain. The default config path is: For tests or isolated profiles, set: The downloader reads this config automatically. If discovery.web of science url is present, scripts/batch download.mjs uses it as the Web of Science entry; otherwise it falls back to https://www.webofscience.com/wos/woscc/basic search . For Chinese literature, the downloader also reads discovery.cnki url when present. If absent, scripts/batch download.mjs title "<中文题名 " falls back to https://kns.cnki.net/kns8s/defaultresult/index . API First and Open Access Fallback For an English article, identify its publisher before deciding when to resolve article level OA: 1. Collect a DOI, PMID, exact title, article URL, or a definite paper list, then normalize its metadata and publisher. 2. If it belongs to Elsevier, Springer Nature, or IEEE and usable provider credentials are configured, try that publisher API first. On success, record accessMode: publisher api and oa status: not checked api first ; do not run OA resolution only to label the article. 3. If the publisher API fails, automatically search legitimate OA sources such as PMC, Unpaywall, publisher OA pages, arXiv, and other lawful repositories or clearly open PDF URLs. Preserve the failed API attempt in the manifest. 4. For all other English publishers, search those legitimate OA sources before Web Access. 5. For an exact title or an explicit OA only request, prefer: Use pdf url when the user supplies a known legitimate OA PDF URL. 6. Verify the downloaded file and record the source. Mark a successful PDF as open access downloaded . 7. If no lawful OA full text is found, mark oa not found . For a supported publisher whose API already failed, request confirmation before Web Access. For another publisher, continue to Web Access. If route open access was explicitly requested, stop after the OA result. Publisher API Credentials Configure credentials lazily, only when the route first needs them: Give the user the official registration link: Elsevier https://dev.elsevier.com/ , Springer Nature https://dev.springernature.com/docs/quick start/api access/ , or IEEE https://developer.ieee.org/member/register . Do not proactively ask the user to paste an API key into chat. If the user voluntarily sends a publisher API key, treat that as authorization to save that exact key: do not reject it, ask them to regenerate it, or repeat it back. Pass it to configure credentials.py set <provider stdin , keep it out of command line arguments, logs, replies, and manifests, then report only the masked confirmation and validation status. The local hidden prompt remains the preferred path when the key has not already been provided. IEEE Metadata API access is not paid full text access; require the issued Full Text Access endpoint/template before treating IEEE as downloadable through the API. Secrets are stored in ~/.config/lit dl/credentials.json with mode 0600 . Resource URL Triage Classify the user provided URL before choosing an access path: If the URL is a login page with a service= parameter, treat the callback host as the resource service and do not make the login page the whole workflow. For example, https://login.university.example/authserver/login?service=https://resources.university.example/callback means the identity service returns to the user's resource portal after authentication. Institution Specific Domains Confirm against what actually appears in the user's address bar; correct these for each institution instead of assuming a preset is complete. Treat configured institutional login, federation, proxy, and database login hosts as sign in stages. Do not treat reaching them as a final failure. Boundaries Use only the user's legitimate institutional access. Do not bypass paywalls, DRM, or two factor authentication. Verification first rule: When a visible slider, checkbox, robot check, or simple verification control appears in the user's authenticated Chrome session, attempt it in the browser before asking the user to intervene. Keep the attempt bounded (at most two attempts on one tab), verify that the challenge disappeared, and continue from that same tab when successful. Slider/drag challenges (including CNKI puzzle sliders): estimate the visible travel distance and simulate a gradual drag. ScienceDirect robot checks, managed Turnstile, and reCAPTCHA checkbox stages: try the visible checkbox once. Simple Continue , Verify , or equivalent visible controls: click once, then re check the page state. User handoff: Ask the user only after the bounded attempt fails, or immediately when the page requires secret or identity bearing input such as an image selection answer, QR approval, SMS/OTP, passkey, hardware key, or two factor authentication. Keep the challenged tab open and never ask the user to paste credentials or codes into chat. Avoid unbounded or indiscriminate downloading. Process only the definite paper list confirmed by the user, apply provider friendly pacing, and leave a clear audit trail of what was downloaded, from where, and whether supporting information was found. Do not ask the user to paste institutional passwords, database passwords, OTP codes, recovery codes, or session tokens into chat or terminal. If the user offers one of those identity bearing secrets, decline and use the handoff login workflow instead. Publisher API keys follow the separate save on receipt rule above. Exception for saved institutional login pages: if the user explicitly says that the browser has already filled credentials and authorizes clicking the visible login/confirm button, the agent may click that button once on the expected institutional SSO / CAS / CARSI / Shibboleth page without reading, copying, or typing any credential. This exception does not apply to CAPTCHA, QR login, SMS/OTP, publisher bot checks, consent/security warnings, or any page outside the expected institutional login flow. Do not inspect or export cookies, passwords, local storage, browser profiles, or session files. Use the browser's already authenticated page context only. Preconditions Before attempting downloads, confirm the conditions that apply to the selected access branch. For the OA only branch, confirm the target paper identifier/list, output folder, Node.js 22+, and Python 3 when PDF verification needs it. Do not require a library configuration or institutional browser login. For the paid library branch, confirm these conditions: 1. The browser that holds the user's library/database login state is open on the user's machine. 2. The school configuration exists and is valid. Run python3 scripts/configure school.py show . If missing, run python3 scripts/configure school.py preset "<school name " or guide the user through src/wizard.py . 3. The user has personally logged in to their institution/library route in that same browser, and can reach the library aggregation service, target database, or discovery entry. 4. The browser control path can reuse that same logged in browser profile. For Chrome CDP, ask the user to open chrome://inspect/ remote debugging and enable remote debugging for the current browser instance. If CDP attaches to a stale browser, a temporary profile, or a different browser, use a browser control channel that can reuse the user's active session instead of launching a new profile. 5. The environment can run Node.js 22+. Try node version . If node is not on PATH in Codex Desktop, try %LOCALAPPDATA%\OpenAI\Codex\bin\node.exe . 6. The environment can run Python 3 for configuration and PDF text verification. Try python3 version . Install Python helpers with pip install r requirements.txt when needed. 7. The web access CDP proxy is available or can be started. Typical Claude Code path: %USERPROFILE%\.claude\skills\web access main\scr