Scientific data ops
268 AI coding assistant skills, organized across 12 workflow layers. Sources include Anthropic official, FRM, SKC, LRN, SKA, and other mainstream AI coding frameworks.
npx -y skills add asong56/skills --skill scientific-data-opsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 17 days oldThe repository was created 17 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Scientific database access across three sources: (1) PubMed — search biomedical and life-sciences literature; (2) USPTO — patents and trademark lookups; (3) gget — genomic data queries (gene lookup, sequence search, expression data, pathways). Incorporates former: scientific-db-pubmed-database, scientific-db-uspto-database, scientific-pkg-gget.
SKILL.md
15.4 KB, as published. Nobody here has run it
PubMed (Biomedical Literature)
PubMed Database
Use this skill when a task needs biomedical literature from PubMed rather than general web search.
When to Use
- Searching MEDLINE or life-sciences literature.
- Building PubMed queries with MeSH terms, field tags, dates, or article types.
- Looking up PMIDs, abstracts, publication metadata, or related citations.
- Running systematic-review search passes that need repeatable search strings.
- Using NCBI E-utilities directly from Python, shell, or another HTTP client.
Query Construction
Start with the research question, split it into concepts, then combine concepts with Boolean operators.
concept_1 AND concept_2 AND filter
synonym_a OR synonym_b
NOT exclusion_term
Useful PubMed field tags:
[ti]: title[ab]: abstract[tiab]: title or abstract[au]: author[ta]: journal title abbreviation[mh]: MeSH term[majr]: major MeSH topic[pt]: publication type[dp]: date of publication[la]: language
Examples:
diabetes mellitus[mh] AND treatment[tiab] AND systematic review[pt] AND 2023:2026[dp]
(metformin[nm] OR insulin[nm]) AND diabetes mellitus, type 2[mh] AND randomized controlled trial[pt]
smith ja[au] AND cancer[tiab] AND 2026[dp] AND english[la]
MeSH and Subheadings
Prefer MeSH when the concept has a stable controlled-vocabulary term. Combine MeSH with title/abstract terms when the topic is new or terminology varies.
Correct subheading syntax puts the subheading before the field tag:
diabetes mellitus, type 2/drug therapy[mh]
cardiovascular diseases/prevention & control[mh]
Use [majr] only when the topic must be central to the paper. It can improve
precision but may miss relevant work.
Filters
Publication types:
clinical trial[pt]meta-analysis[pt]randomized controlled trial[pt]review[pt]systematic review[pt]guideline[pt]
Date filters:
2026[dp]
2020:2026[dp]
2026/03/15[dp]
Availability filters:
free full text[sb]
hasabstract[text]
E-utilities Workflow
NCBI E-utilities supports repeatable API workflows:
esearch.fcgi: search and return PMIDs.esummary.fcgi: return lightweight article metadata.efetch.fcgi: fetch abstracts or full records in XML, MEDLINE, or text.elink.fcgi: find related articles and linked resources.
Use an email and API key for production scripts. Store API keys in environment variables, never in committed files or command history.
import os
import time
import requests
BASE = "https://eutils.ncbi.nlm.nih.gov/entrez/eutils"
def esearch(query: str, retmax: int = 20) -> list[str]:
params = {
"db": "pubmed",
"term": query,
"retmode": "json",
"retmax": retmax,
"tool": "ecc-pubmed-search",
"email": os.environ.get("NCBI_EMAIL", ""),
}
api_key = os.environ.get("NCBI_API_KEY")
if api_key:
params["api_key"] = api_key
response = requests.get(f"{BASE}/esearch.fcgi", params=params, timeout=30)
response.raise_for_status()
time.sleep(0.35)
return response.json()["esearchresult"]["idlist"]
pmids = esearch("hypertension[mh] AND randomized controlled trial[pt] AND 2024:2026[dp]")
print(pmids)
For batches, prefer NCBI history server parameters (usehistory=y,
WebEnv, query_key) instead of passing very long PMID lists through URLs.
Output Discipline
For each search pass, record:
- exact search string
- database searched
- date searched
- filters used
- result count
- export format
- any manual exclusions
Example:
| Database | Date searched | Query | Filters | Results |
| --- | --- | --- | --- | ---: |
| PubMed | 2026-05-11 | `sickle cell disease[mh] AND CRISPR[tiab]` | 2020:2026[dp], English | 42 |
Review Checklist
- Are field tags valid PubMed tags?
- Are MeSH terms paired with free-text synonyms for newer topics?
- Is the date range explicit and appropriate?
- Does the search log include enough detail to reproduce the query?
- Are API keys loaded from the environment?
- Does HTTP code call
raise_for_status()or otherwise handle non-200 responses before parsing? - Are rate limits respected?
References
USPTO (Patents & Trademarks)
USPTO Database
Use this skill when a task needs official United States patent or trademark records from USPTO systems.
When to Use
- Searching granted patents or pre-grant publications.
- Checking patent application status, file-wrapper data, assignments, or public prosecution history.
- Looking up trademark status, documents, or assignment history.
- Building reproducible prior-art, portfolio, or IP landscape research logs.
- Comparing USPTO records with secondary tools such as Google Patents, Lens.org, Semantic Scholar, or company patent pages.
Do not use this skill to give legal advice. Treat it as a data-gathering and record-verification workflow.
Source Selection
Prefer official USPTO or USPTO-supported surfaces first:
- Open Data Portal (ODP): current home for migrated USPTO datasets and APIs.
- Patent File Wrapper: public patent application bibliographic data and file wrapper records.
- PatentSearch API: PatentsView search API for granted patents and pre-grant publication datasets.
- TSDR Data API: trademark status and document retrieval.
- Patent and Trademark Assignment Search: ownership transfer records.
- PTAB data in ODP: Patent Trial and Appeal Board proceedings.
Use secondary sources only as convenience indexes. When the answer matters, cross-check the official record.
Authentication and Secrets
Many USPTO API flows require an API key. Store keys in environment variables or a secret manager, never in committed files or pasted transcripts.
Common environment names:
export USPTO_API_KEY="..."
export PATENTSVIEW_API_KEY="..."
For PatentSearch, send the key with the X-Api-Key header. For TSDR, follow
the current USPTO API Manager instructions and rate-limit guidance.
PatentSearch Workflow
Use PatentSearch for broad patent and pre-grant publication search when the question is about trends, inventors, assignees, classifications, dates, or portfolio slices.
Workflow:
- Identify the endpoint from the current PatentSearch reference or Swagger UI.
- Build a JSON query with explicit filters.
- Request only the fields needed for the analysis.
- Sort and paginate deterministically.
- Record the endpoint, query body, date, data currency note, and result count.
Python request skeleton:
import os
import requests
API_KEY = os.environ["PATENTSVIEW_API_KEY"]
BASE = "https://search.patentsview.org/api/v1"
payload = {
"q": {
"_and": [
{"patent_date": {"_gte": "2024-01-01"}},
{"assignees.assignee_organization": {"_text_any": ["Google", "Alphabet"]}},
]
},
"f": ["patent_id", "patent_title", "patent_date"],
"s": [{"patent_date": "desc"}],
"o": {"per_page": 100, "page": 1},
}
response = requests.post(
f"{BASE}/patent/",
headers={"X-Api-Key": API_KEY, "Content-Type": "application/json"},
json=payload,
timeout=30,
)
response.raise_for_status()
print(response.json())
Before reusing a query, verify current endpoint names, field paths, request parameters, and API-key availability in the live PatentSearch docs.
Trademark/TSDR Workflow
Use TSDR when the task needs trademark case status, documents, images, owner history, or prosecution events.
Workflow:
- Normalize the serial number or registration number.
- Check the current TSDR API instructions and required API-key header.
- Fetch status first, then documents only if needed.
- Respect the lower rate limit for PDF, ZIP, and multi-case downloads.
- Capture retrieval date and serial/registration identifier in the output.
For large trademark pulls, prefer documented bulk-data flows rather than screen-scraping public pages.
File Wrapper and Prosecution History
For application status, transaction history, and prosecution documents:
- Start with ODP Patent File Wrapper search.
- Use exact identifiers when available: application number, publication number, patent number, or party name.
- Record whether the record is a granted patent, pre-grant publication, or pending application.
- Cross-check document dates and status against the record detail page before citing them.
Assignment Workflow
For patent or trademark ownership:
- Search official assignment data by patent/application/registration number, assignor, assignee, or reel/frame when available.
- Record conveyance text, execution date, recordation date, and parties.
- Distinguish assignment records from current legal ownership conclusions.
- If ownership is material, flag the result for attorney or subject-matter review.
Reproducible Output
Every USPTO research pass should include a log table:
| Source | Date searched | Identifier/query | Filters | Results | Notes |
| --- | --- | --- | --- | ---: | --- |
| PatentSearch | 2026-05-11 | `assignee=Alphabet AND date>=2024` | patent endpoint | 118 | API docs checked before run |
| TSDR | 2026-05-11 | `serial=90000000` | status only | 1 | API-key flow, no document bulk pull |
For final writeups, separate:
- official record facts
- inferred analysis
- secondary-source convenience matches
- unresolved gaps or records that require legal review
Review Checklist
- Did you use an official USPTO or USPTO-supported source first?
- Did you verify current endpoint and field names before running code?
- Are API keys kept out of files, shell history, and output logs?
- Does the query log include the date searched and exact request shape?
- Are rate limits respected?
- Are legal conclusions avoided or explicitly escalated?
- Are secondary sources labeled as secondary?
References
- USPTO APIs catalog
- USPTO Open Data Portal
- PatentSearch API reference
- PatentSearch API updates
- TSDR API bulk download FAQ
gget (Genomic Data)
gget
Use this skill when a task needs quick bioinformatics lookup across genomic
reference databases with the gget CLI or Python package.
When to Use
- Finding Ensembl IDs, gene metadata, transcript details, or sequences.
- Running quick BLAST or BLAT lookups without building a full local pipeline.
- Fetching reference genome links and annotations from Ensembl.
- Querying protein structure, pathway, cancer, expression, or disease-association modules through a single interface.
- Creating a reproducible first-pass evidence log before moving to heavier tools such as Biopython, Snakemake, Nextflow, BLAST+, or database-specific clients.
Use a dedicated workflow instead of gget when the task requires regulated
clinical interpretation, high-throughput production pipelines, or fine-grained
control over database versions and local indexes.
Installation
Use a clean Python environment.
python -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install --upgrade gget
gget --help
If uv is available:
uv venv
. .venv/bin/activate
uv pip install gget
Before relying on an older environment, upgrade gget and re-check the module
docs. The upstream databases queried by gget change over time.
Basic Patterns
CLI shape:
gget <module> [arguments] [options]
Python shape:
import gget
result = gget.search(["BRCA1"], species="human")
print(result)
Common workflow:
- Identify the species, assembly, gene ID type, and database needed.
- Check the current module documentation for arguments.
- Run a small query first.
- Save output with an explicit filename and date.
- Record module name, version, arguments, and database assumptions.
Common Modules
Use current upstream docs for exact arguments. These modules are common first choices:
gget search: find Ensembl IDs from search terms.gget info: retrieve metadata for Ensembl, UniProt, or related IDs.gget seq: fetch nucleotide or amino-acid sequences.gget ref: retrieve reference genome download links.gget blast: run a quick BLAST query.gget blat: locate a sequence against supported genome assemblies.gget muscle: run multiple sequence alignment.gget diamond: run local sequence alignment against reference sequences.gget alphafoldandgget pdb: inspect protein-structure references.gget enrichr,gget opentargets,gget archs4,gget bgee,gget cbio, andgget cosmic: explore enrichment, target, expression, cancer, and disease association data.
Do not assume every module supports every Python version or dependency set. Some optional scientific dependencies have narrower version support than the core package.
Quick Examples
Find genes:
gget search -s human brca1 dna repair -o brca1-search.json
Fetch gene metadata:
gget info ENSG00000012048 -o brca1-info.json
Fetch a sequence:
gget seq ENSG00000012048 -o brca1-seq.fa
Run a small BLAST query:
gget blast "MEEPQSDPSVEPPLSQETFSDLWKLLPEN" -l 10 -o blast-results.json
Python example:
import gget
genes = gget.search(["BRCA1", "DNA repair"], species="human")
info = gget.info(["ENSG00000012048"])
sequence = gget.seq("ENSG00000012048")
Reproducibility Log
For scientific outputs, include enough metadata to replay the query.
| Date | gget version | Module | Query | Species/assembly | Output | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| 2026-05-11 | `gget --version` | search | `BRCA1 DNA repair` | human | `brca1-search.json` | Docs checked before run |
Also record:
- Python version and environment manager.
- Any optional dependency installed through
gget setup. - Database-specific identifiers returned by the query.
- Whether output is JSON, CSV, FASTA, or a DataFrame export.
- Any failures that were resolved by upgrading
gget.
Review Checklist
- Did you upgrade or verify the installed
ggetversion? - Did you check the current upstream module docs before using arguments?
- Is the species or assembly explicit?
- Are identifiers preserved exactly, including Ensembl/UniProt prefixes?
- Is the result labeled as database output rather than clinical interpretation?
- Is the query reproducible from the saved command or Python snippet?
- Are optional dependencies installed in an isolated environment?
References
Gives 0 of the 12 instructions most ship operate skills give
Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-06
- document a rollback plan before deploymentin 40 of 779, across 21 files
- create an annotated git tagin 21 of 779, across 20 files
- Run the test suitein 20 of 779
- update the changelogin 20 of 779, across 18 files
- verify deployment health after launchin 19 of 779, across 10 files
- clean up feature flags after full rolloutin 18 of 779, across 10 files
- verify the working tree is cleanin 18 of 779
- test both feature flag statesin 17 of 779, across 9 files
- Make database migrations backward-compatiblein 16 of 779, across 8 files
- set up error monitoring before launchin 15 of 779, across 7 files
- monitor metrics at each rollout stagein 14 of 779, across 5 files
- create a github releasein 14 of 779
Said here and by no other author read
- record exact query and date for every search
- respect api rate limits
- use an email and api key for production scripts
- handle non-200 responses before parsing
- use official sources first
- verify endpoint and field names before running code
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.