* fix(skills): move version into metadata and normalize to semver 29 skills declared `version` at the top level of their frontmatter. The schema reads it from `metadata`, so tooling that follows the schema either misses it or has to special-case the top level. Three motion skills also declared `version: 1.0`, which is not a valid semantic version; normalized to `1.0.0`. No behavioral change — frontmatter metadata only. * fix(skills): state activation triggers in skill descriptions 148 skills described what they cover but never named the situation that should trigger them. Since the description is what Claude matches against to decide whether to load a skill, a description without a trigger makes activation guesswork — the skill is either missed or loaded at the wrong time. Added a "Use when ..." clause to each, derived from the skill's own body (most already stated the trigger under "## When to Use" or in the opening line; that intent is now reflected in the frontmatter where it is actually read from). Descriptions were only appended to; no existing wording was removed. * fix(skills): sync activation triggers into the Codex skill mirror 10 of the skills whose descriptions changed are also mirrored under `.agents/skills/`, where the description was previously a verbatim copy. Left alone, the two surfaces would disagree about when the skill applies. Only the description line is synced; the Codex copies keep their reduced frontmatter, since that validator accepts only name, description, metadata, license, and allowed-tools. * fix(skills): correct three activation clauses from review - autonomous-loops: the clause pulled new loop work into a skill that its own body marks as a compatibility shim retained for one release. It now points at the canonical continuous-agent-loop instead. - continuous-learning: the description carried the v1 routing directive twice; collapsed to one. - homelab-pihole-dns: the clause fired on any broken home DNS. Narrowed to tasks that actually involve Pi-hole. * chore: retain current main lockfile --------- Co-authored-by: Çağrı Solakoğlu <cagri.solakoglu@vtcenerji.com> Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
4.7 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| pubmed-database | Direct PubMed and NCBI E-utilities search workflows for biomedical literature, MeSH queries, PMID lookup, citation retrieval, and API-backed literature monitoring. Use when a task needs biomedical literature from PubMed rather than general web search. |
|
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?