Identify the project before installing anything
The name dsh-scholar does not establish a universal academic-search package. The inspected lzszq/dsh-scholar README describes a supervised computational-research workspace with explicit research decisions and execution prerequisites. Other repositories use similar names for different integrations. Record the owner, repository, revision, host and actual installation documentation before choosing an implementation. Do not substitute a similarly named package or assume that a DSH plugin is a skill folder that every agent can load.
This guide's original example is a student surveying urban tree shade and pedestrian thermal comfort. It describes a proposed research workflow, not an executed search or a completed review. No paper titles, identifiers or results are invented. The three outputs are a multi-source search ledger, a repeatable tracking record and a reviewed bibliographic library. These are useful even when a particular plugin is unavailable.
Scenario one: search several sources without losing provenance
Write the question before searching: which street setting, which shade exposure, which pedestrian outcome, and which period matter? Separate measured thermal comfort from general discussion of urban greenery. Build English and Chinese synonym groups for the concepts, then adapt the query to each source's supported syntax. A translated keyword is a starting point, not proof that the two searches cover the same literature.
Use one small first pass to check terminology. Inspect a few relevant and irrelevant records and revise the query with a reason. Retain the initial query rather than overwriting it. A narrower result set can reflect better precision or a missed synonym; its size alone cannot decide which. Record the database, complete query, filters, retrieval time, pagination and any failed requests. Do not treat a limited first page as an exhaustive search.
For every candidate, retain title, authors, date, stable source identifier, DOI where actually supplied, original record link and the evidence available. Distinguish metadata, abstract and accessible full text. A PDF link does not demonstrate that the paper was downloaded or read. A generated summary based on an abstract must say so. If a claim depends on methods or limitations, inspect the relevant full-text passage before using it.
Deduplicate first by reliable identifiers, then review possible title matches. A preprint and its journal version may represent the same work while differing in content. Keep their relationship instead of deleting one indiscriminately. Similar titles with different authors are not necessarily duplicates. Add inclusion and exclusion reasons tied to the question, such as wrong setting or no pedestrian outcome. Citation counts and search rank are discovery signals, not substitutes for reading or quality assessment.
The deliverable is a ledger that another researcher can inspect and repeat. Preserve unresolved metadata conflicts. Do not turn unavailable full text into an invented methods section. If an API is rate-limited, retain the failure, follow its supported retry guidance and resume without duplicating already stored records. One unavailable source should be reported as a coverage limitation rather than silently represented as having no relevant work.
Scenario two: track new papers with explicit windows
A daily tracker needs a defined query, date interpretation, time zone, source and last successful retrieval. Publication date, submission date and indexing date are different concepts. Choose the one supported by the source and appropriate to the question. Use an intentional overlap when needed to catch delayed indexing, then deduplicate by identifiers. Otherwise a failed run or a late record can create an invisible gap.
For the tree-shade example, propose a daily batch of new candidates grouped by relevance reason. Retain why each was selected and whether it is a new work or a revision. The batch is a screening aid, not a recommendation to cite every record. A changed preprint should retain its version and retrieval date so a later reader can identify what was reviewed.
Keep successful zero-result runs separate from failed or partial runs. Store source errors and incomplete pages with the batch status. Resume from the last reliable checkpoint rather than advancing a date merely because the scheduler fired. Check a sample of known relevant records to detect a broken query or changed interface. Do not create a recurring email or message delivery as an incidental part of research planning; scheduling and recipients require their own authorized setup.
The output is a dated batch, checkpoint and status record. For a proposed schedule, say that it is proposed. A sample digest in a document is not evidence that a scheduled job is installed or that notifications were delivered. Keep operational ownership clear: somebody must notice repeated failures and decide when a query needs revision.
Scenario three: move reviewed records into a library
Verify title, author list, year, venue and identifier against an authoritative record before importing. A plausible-looking DOI string is not enough. Preserve missing fields as missing and resolve disagreements explicitly. An identifier lookup can improve metadata without establishing that the article's findings are correct or that full text is licensed for redistribution.
Export a small reviewed set first. Keep a backup of the existing bibliography and import into a temporary collection or copy. Check that citation keys are unique, special characters survive, titles retain necessary capitalization and the target citation workflow can read the format. Review a formatted citation as well as the underlying entry. Do not append duplicate entries repeatedly when a task is rerun.
For each reading note, retain the original source and the evidence level. Separate an author's finding, the researcher's interpretation and an unanswered question. If a summary says shade improved comfort, record the setting, measurement and limitations before generalizing to other climates. This is a literature-management example, not a factual claim that a particular study found such an effect.
Full-text downloads must follow actual access and reuse conditions. A public metadata endpoint does not grant access to every publisher PDF. Keep local files organized with stable identifiers rather than relying only on titles that may change. A useful library handoff includes the verified entries, version relationships, screening reasons, source links and unresolved access gaps.
A bounded first task
Ask the agent to propose a search plan for urban tree shade and pedestrian thermal comfort, specifying concepts, synonyms, sources and inclusion rules. Request a small candidate ledger first, with original links and separate metadata, abstract and full-text labels. Ask it to report failed sources and missing fields. Do not request invented examples of real citations, unrestricted downloads or immediate manuscript publication. Inspect the first ledger before enabling a larger retrieval or import.
Installation is a separate checkpoint. Read the complete package and its dependencies, identify the supported host and required external services, and use that host's documented route. An instruction package does not supply credentials, library access or background execution automatically. Check discovery, selection and successful execution independently. Do not guarantee identical setup across clients or assume public APIs and model usage have no costs or limits.
Troubleshooting and acceptance
If results are empty, distinguish a valid query with no matches from syntax errors, rate limits and incomplete retrieval. If two sources disagree, compare identifiers and versions before merging. If a bibliography import fails, test a small copy and retain the original library. If a summary makes unsupported claims, return to the evidence level and the actual passage used. Increasing the number of retrieved records does not repair weak provenance.
Accept the workflow only when a sample query can be reconstructed, candidate links resolve, duplicate decisions are explainable and the exported bibliography imports without damaging existing entries. Record which sources and formats were actually checked. A demonstration using one database does not verify universal multi-source support. A planned daily run remains unverified until its checkpoints and failure handling have been exercised.
Optional skill association and sources
Notion Research & Documentation fits an optional handoff after reviewed notes have been placed in authorized Notion pages. It can organize those sources into a cited brief. It requires connected Notion tools, readable source pages and a named writable destination. It does not search academic databases, validate DOI or BibTeX, or establish that full text was read. Its pinned source and MIT evidence are checked; static scanning and runtime behavior remain separate, unverified signals.
References are the identified DSH Scholar repository, arXiv API guidance, Crossref metadata documentation and the original Chinese and English articles retained together in the editorial record. This tree-shade workflow is an original teaching case; no search, recurring schedule or library write is claimed as executed.