chrome-paper-download

name

chrome-paper-download

description

Use when finding academic papers through Chrome or Google Scholar, checking publisher or library SSO access for a user-specified institution, downloading authorized PDFs, exporting BibTeX, or adding reusable publisher-site download notes. Must be used together with chrome-mcp for Chrome control; use Chrome DevTools MCP as the browser-control surface for tab/page selection, navigation, clicks, screenshots, downloads, and page inspection.

Chrome Paper Download

Overview

Use the user's Chrome session to find papers, use saved SSO sessions when available, download authorized PDFs, and export BibTeX into the calling project's working directory. Keep publisher-specific behavior in references/sites/ so the next run can reuse the known path.

Mandatory Browser Surface

Use this skill together with chrome-mcp. Chrome DevTools MCP is the required browser-control surface for this skill: use it to list/select pages, foreground tabs, navigate, click publisher controls, inspect DOM/page state, capture screenshots, monitor download-triggering actions, and recover from stale or blocked pages.

The required browser session is the user's visible/saved Chrome session, with the user's cookies, SSO state, account chooser, downloads, and password manager. Prefer chrome-mcp with its real-profile attachment (--autoConnect) so the workflow stays in that saved Chrome context. Do not replace it with the bundled Chrome/Browser/computer-use extension, a separate headless Chrome profile, raw HTTP scraping, standalone Playwright/Selenium, or direct chrome.exe --headless for discovery, access checks, downloads, BibTeX export, or webpage-to-PDF capture.

Before any paper-download browser work, read and follow the bundled sibling skill chrome-mcp. If Chrome DevTools MCP tools are not visible or cannot attach to the user's real Chrome session, stop and report that chrome-mcp is unavailable instead of falling back to the bundled Chrome extension or headless/raw download routes.

Raw HTTP/API calls are allowed only for non-authoritative bookkeeping after the Chrome path has been attempted, such as verifying saved file bytes or looking up a DOI to help identify a publisher page. They must not be used to bypass Chrome, SSO, publisher UI, CAPTCHA, anti-bot checks, or download restrictions.

Required References

1. Read references/common-workflows.md before starting any paper-download task.
2. Read references/sites/index.md and the matching site record when the publisher domain is known.
3. If the publisher domain is not documented, follow the common workflow and create a new site record from references/sites/site-template.md after the run.

Operating Rules

• Use chrome-mcp first and throughout the paper-download workflow. If Chrome DevTools MCP is unavailable, cannot list/select Chrome pages, or cannot control the user's real Chrome session, stop and report that the required browser surface is unavailable instead of falling back to the bundled Chrome extension, headless automation, or raw HTTP downloads.
• Google Scholar, publisher access checks, institutional SSO, PDF downloads, publisher BibTeX exports, and webpage-to-PDF capture must happen in the user's Chrome session.
• On Google Scholar result pages, treat the title/main-result link as the primary route. Open that link first to reach the publisher or canonical landing page. Side links such as [PDF], mirrors, repositories, or title-adjacent PDF links are fallback routes only after the main-result link fails, is not usable, or cannot provide access/citation.
• Handle exactly one paper at a time. Do not write or run code that batch-downloads, loops over a manifest, or queues multiple papers. Do not create helper scripts whose purpose is to download multiple papers. Each paper can have different publisher UI, SSO, CAPTCHA, download-folder behavior, save-dialog behavior, and failure modes; complete and record one paper before choosing the next.
• Before every site operation, bring the target Chrome tab/window to the foreground and make it the active visible page. Do this before navigation, clicking, SSO checks, PDF viewer actions, download buttons, citation export, and save-dialog confirmation. If an otherwise valid Chrome action appears to do nothing or times out, first foreground/activate the target tab and retry once before diagnosing the site or plugin as failed.
• If SSO is not already logged in, pause at the visible login/account-chooser screen and ask the user to complete one SSO login in Chrome. If Chrome offers to save the password/session, ask the user to save it if they are comfortable doing so; never type, store, or infer credentials yourself.
• If Chrome shows This page has been blocked by Chrome, This page has been blocked, or 此页面已被 Chrome 屏蔽, refresh/reload the same tab once and wait for the page to reload before treating the access or download as failed.
• Save all deliverables to the invoking project's current working directory unless the user explicitly gives another directory.
• Export both *.pdf and *.bib when SSO access is available and PDF download is allowed.
• Prefer official publisher BibTeX that includes the abstract. If the citation UI offers Citation & Abstract, Include abstract, or a similar option, select it before downloading. Do not treat an existing DOI/Crossref/local BibTeX as sufficient until the publisher or Scholar path has been attempted for that individual paper.
• If a publisher citation modal shows text such as Loading Citation ..., wait several seconds for the citation body to appear before deciding it is stuck. If it is still stuck, refresh/reload the same article page once, open the citation export again, and wait several seconds again. Use Google Scholar Cite -> BibTeX fallback only after the refreshed retry also fails, and save the Scholar BibTeX exactly as provided. Do not manually add DOI, URL, abstract, publisher fields, or otherwise edit the Scholar BibTeX; record missing fields in the manifest/site notes instead.
• If the site does not support institutional SSO, the target institution is missing from the institution list, login fails, access is denied, or the download is blocked, export only *.bib and record the reason.
• If a matching site record says the target institution is not registered, access is unavailable, or PDF download is citation-only for that publisher, do not retry the PDF path for later papers on that site. Export or verify only the citation/BibTeX unless the user explicitly says access has changed.
• Do not bypass paywalls, organization policy, two-factor prompts, or credential entry. If a webpage shows a simple visible verification such as a CAPTCHA checkbox, browser check, or "verify you are human" tick box, you may try the visible verification once in Chrome. If it does not pass, asks for image/audio/text challenges, or loops back to verification, stop and ask the user to complete it.
• After clicking any visible publisher PDF/download control, check Chrome's configured download directory, normally the user's Downloads folder, for newly created PDFs before concluding that no navigation, PDF viewer, or Save As dialog appeared. Move/rename only a verified PDF into the project target path.
• If the publisher PDF link uses a download URL such as ?download=true, Chrome may complete the download while the active page still appears unchanged, blocked, or stale. Refresh/open Chrome's downloads UI and check the configured download folder for newly completed files before treating the PDF route as failed. If a verified %PDF- file is present, copy or move it to expectedPath with expectedFilename.
• Before opening a Save As dialog or confirming any download, resolve the exact final filename and target directory. If a user, source list, manifest, existing project numbering, or prior run implies a numbered prefix such as 24_, preserve it. If the computed filename differs from the expected filename, stop and report the mismatch instead of saving with the wrong name.
• Verify saved PDFs by checking the first bytes start with %PDF- and by confirming a non-trivial file size.
• Whenever a publisher PDF or BibTeX path is learned, corrected, or materially confirmed, immediately update the matching references/sites/<publisher-slug>.md record before relying on the method for future papers. If the site is undocumented, create a new site record from the template and add it to the index.
• Whenever a run reveals a general workflow rule or a prior skill gap, immediately update this SKILL.md, references/common-workflows.md, references/sites/site-template.md, and the matching site record before moving to the next paper.
• After each paper's PDF and BibTeX handling is complete, force a per-paper process review before moving to the next paper. Review the whole run and decide whether this SKILL.md, references/common-workflows.md, references/sites/site-template.md, or the matching references/sites/<publisher-slug>.md needs an update. Update any file that gained a new general rule, UI text, selector, URL pattern, SSO state, failure mode, filename/save-dialog behavior, or tab-cleanup behavior. If nothing changed, explicitly keep the skill and site records unchanged and continue.
• Before selecting or navigating to the next paper, complete the per-paper cleanup gate: close the current paper article page, PDF viewer, citation drawer/modal, BibTeX page, temporary Google Scholar tab, and any native Save As/file picker/download windows. If a tab or dialog must stay open for login, SSO handoff, or a blocked/manual step, explicitly record why and do not start another paper in that same browser/window state.
• Before typing or pasting any next-paper URL/search, enumerate visible windows and confirm the foreground target is the intended Chrome tab/address bar, not File Explorer, a native Save As dialog, a Downloads window, or a browser PDF save/download dialog. If focus is uncertain, stop and re-foreground Chrome; never paste a URL while a save/file dialog or Explorer window can receive input.

Outputs

Use stable, filesystem-safe names based on the paper title:

• <sanitized-title>.pdf
• <sanitized-title>.bib

If the current paper has a known sequence number or prefix from the user's list, project manifest, existing file order, or visible task context, include it in the basename before the sanitized title, e.g. 24_Measuring_contrast_sensitivity.pdf. Do not silently drop, invent, or renumber prefixes. If the prefix is ambiguous, stop and ask/report the ambiguity before saving.

Sanitize filenames before every save or rename. For the basename, keep only ASCII letters and digits; replace every run of other characters with a single underscore; trim leading/trailing underscores; then append the literal extension .pdf or .bib. Do not put backslashes, slashes, colons, quotes, DOI punctuation, query strings, or other special characters into the filename field.

Before saving, create an explicit filename gate:

• expectedDirectory
• expectedFilename
• expectedPath = expectedDirectory/expectedFilename

Compare every observed or computed filename against expectedFilename. If the active dialog, download shelf, suggested filename, or local target path contains a different basename, stop with a clear error such as Filename mismatch: expected 24_Measuring_contrast_sensitivity.pdf, got Measuring_contrast_sensitivity.pdf. Do not press Enter or click Save until the mismatch is resolved.

When a download or Save As dialog appears, change only the filename field to the final sanitized filename, such as 24_Measuring_contrast_sensitivity.pdf, then click Save. Do not paste a full filesystem path into the filename field. If the dialog is not already in the target project folder, navigate the folder/address separately first, then change only the filename.

When a save dialog suggests a URL-like name such as getPDF.jsp, replace that filename with the sanitized final filename before confirming.

For Windows native Save As dialogs, do not trust blind keystrokes or screenshot-only coordinates:

• After navigating the folder/address field, verify the dialog address shows expectedDirectory.
• Confirm focus is on the filename field before typing or pasting. Re-read the field value or inspect the visible filename before pressing Save.
• If coordinates are needed, get them from UI-inspected control bounds/clickable points after accounting for Windows DPI scaling and current dialog position. If the control is clipped or outside the visible screen, move the dialog into view or stop.
• If Windows reports 找不到文件, cannot find the file, or similar after entering the target filename, treat it as evidence that text went into the address/navigation field. Dismiss the warning, refocus the filename field, revalidate folder and filename, retry once, then stop if focus is still uncertain.

Updating Site Records

After any new publisher site, or after learning/correcting a PDF or BibTeX route for an existing publisher:

1. Add references/sites/<publisher-slug>.md.
2. Record SSO support for the user-specified target institution.
3. Record exact UI text, selectors, URLs, and failure modes observed.
4. Add the site to references/sites/index.md.
5. For existing site records, update the PDF Download and BibTeX Export sections with the observed route, including whether it was verified through Chrome + SSO.
6. After each individual paper is finished, re-check the matching site record and either update it with new observations or leave it unchanged when the route was already documented.
7. Mark unverified behaviors explicitly as not verified.