From eff612c8dad0f84bc85dd74a8989de1126f8478d Mon Sep 17 00:00:00 2001 From: promptadmin Date: Mon, 10 Aug 2026 09:57:27 +0000 Subject: [PATCH 1/2] [upstream-sync] skills/tooluniverse-biomedical-fact-lookup/SKILL.md from mims-harvard/ToolUniverse@8e9110ec [unknown] --- .../SKILL.md | 108 +++++++++++++++++- 1 file changed, 104 insertions(+), 4 deletions(-) diff --git a/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-biomedical-fact-lookup/SKILL.md b/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-biomedical-fact-lookup/SKILL.md index 86c3b91f..a402bb60 100644 --- a/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-biomedical-fact-lookup/SKILL.md +++ b/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-biomedical-fact-lookup/SKILL.md @@ -1,8 +1,8 @@ --- lineage_type: import -upstream_source: https://github.com/mims-harvard/ToolUniverse/blob/cfd26718/skills/tooluniverse-biomedical-fact-lookup/SKILL.md -upstream_sha: cfd26718 -imported_at: 2026-08-08 +upstream_source: https://github.com/mims-harvard/ToolUniverse/blob/8e9110ec/skills/tooluniverse-biomedical-fact-lookup/SKILL.md +upstream_sha: 8e9110ec +imported_at: 2026-08-10 prompt_class: unknown upstream_changes: accepted name: tooluniverse-biomedical-fact-lookup @@ -43,9 +43,59 @@ Most of these questions are MCQ with an "Insufficient information to answer the | **drug / compound** target, MoA, approval | `ChEMBL_*`, `OpenFDA_*`, `GtoPdb_*`, `PubChem_*` | resolve drug, query the relation | | **which drug for this patient** (clinical vignette naming a modifier) | `FDA_*_by_drug_name` — pick the section by modifier | see "Drug choice for a described patient" below | | **protein** function / domain / sequence | `UniProt_*` | resolve accession, read annotation | +| **protein localization / expression** "according to the Human Protein Atlas" | `HPA_get_subcellular_location`, `HPA_get_rna_expression_by_source`, `HPA_get_comprehensive_gene_details_by_ensembl_id` | pass the gene symbol — an **antibody ID such as `HPA073143` also works** and resolves to its target gene. **Report main *and* additional locations** — see below | + +| **brain region** in the Allen Mouse/Human Brain Atlas | `AllenBrain_search_structures` (`name` or `acronym`), `AllenBrain_get_structure` | reference-atlas regions are **colour-coded**: the result carries `color_hex_triplet`, so "the region shown in red" is answerable — see below | +| **regulatory element / cCRE** near a gene (ENCODE SCREEN) | `SCREEN_search_cCREs_by_region` | filter on `element_type` (**PLS** and **pELS** are TSS-proximal, **dELS** distal) and read `dnase_zscore` | +| **which variant is at / overlaps** a genomic region (ClinVar) | `ClinVar_search_by_region` | **not** `ClinVar_search_variants` — Entrez matches a variant's START, so a narrow window misses a CNV that spans the region but begins megabases upstream. Returns true overlaps, smallest span first | +| **how many peaks / which datasets** for a TF experiment (ReMap) | `ReMap_list_datasets_for_target` | one GEO series can hold several datasets (GSE23852/FOXA1 = 2, with 60,158 and 67,736 peaks) — report them separately unless a total is asked for; `count_peaks: true` to get counts | +| **protein interaction partners** (STRING) | `STRING_get_protein_interactions` | read the **`partner`** field, not `preferredName_B`: edges are ordered A/B by internal ID, so the queried protein sits in column A on about half of them | When unsure which tool wraps a database, search the catalog by the *relation* (e.g. "gene disease association", "gene set members"), not the brand name — ToolUniverse usually already has it. +### Allen Brain Atlas — answer with the specific structure, not its parent + +The reference atlas colours every structure, and `AllenBrain_search_structures` +returns `color_hex_triplet`. A question naming a colour ("which region is +annotated in red at coronal position 181") is asking which **leaf structure** +carries that colour, e.g. `Lateral preoptic area` = `#F2483B`. + +Answering with the enclosing region ("Hypothalamus") is wrong even though it +contains the right area: the atlas colours the specific structure, and the +parent has its own different colour. Search by name or acronym, compare +`color_hex_triplet`, and give the structure whose colour matches. Note the same +acronym can return several rows (hemisphere-specific and ontology-version +entries) with different colours — prefer the row whose `name` matches the +question's wording. + +### Human Protein Atlas — report both location fields + +`HPA_get_subcellular_location` splits its answer in two, and the split is not +significance ranking: + +``` +main_locations : ['Nucleoplasm'] +additional_locations : ['Primary cilium', ..., 'Cytosol'] +``` + +A question asking "what localization does this antibody show" wants the +locations HPA reports, which is **both lists** — answering from `main_locations` +alone drops real localizations and is a common way to be half-right (e.g. +answering "Nucleoplasm" where HPA reports "Nucleoplasm, Cytosol"). Use +`location_summary`, which already joins them, or read both fields. + +Two further cautions: + +- **Locations aggregate over cell lines.** HPA pools immunofluorescence across + every line an antibody was tested in. If the question names one line (HEK293, + U-2 OS), treat the list as the candidate set and say which line you are + reporting for, rather than implying the aggregate is line-specific. +- **Per-cell-type RNA values are only published for enriched cell types.** HPA's + machine-readable fields give specificity plus nTPM/nCPM for the cell types a + gene is enriched in; a value for an arbitrary cell type is not exposed. If a + question asks for one that is absent, say so instead of substituting the + nearest available number — those differ by an order of magnitude. + ## MSigDB set-name conventions (the most common LAB-Bench pattern) ToolUniverse's `MSigDB_*` tools cover several collections that LAB-Bench questions are built from. Get the set name right: @@ -127,6 +177,42 @@ Try the `MP_` MSigDB set first (above): it answers in one call per op ## Computational procedures (when the answer is COMPUTED, not looked up) +### GWAS "highest p-value" means most significant + +In GWAS writing, "the highest p-value", "the top hit" and "the strongest +association" all mean the **most significant** result — the *smallest* numeric +p-value. Read literally, "highest" picks the weakest association in the study +and is almost never what was meant. + +For GCST005528 the literal reading gives `rs2476491-?` at p = 1e-06; the +intended answer is `rs7775055-G` at p = 3e-174. + +Sort ascending by p-value and report that hit. If the phrasing genuinely could +go either way, give the most significant one and say in a clause that the +numerically largest p-value is a different SNP — do not silently pick the +literal reading. + +### Genomic windows — count the anchor base + +A window described as "N bp upstream plus M bp downstream of X" spans +**N + M + 1** bases, because the anchor base X is itself included. Asking for +100 up and 100 down around a TSS is 201 nt, not 200. Off-by-one here is the +single most common way a sequence answer is wrong while looking right. + +The same care applies to the coordinate convention of whichever tool you call: + +| convention | span of `start`..`end` | used by | +|---|---|---| +| 1-based inclusive | `end - start + 1` | Ensembl `region`, UCSC browser text, IGV, samtools | +| 0-based half-open | `end - start` | UCSC REST API, BED | + +`UCSC_get_sequence` takes a written locus via `region` (1-based inclusive) or +explicit `chrom`/`start`/`end` with `coordinate_system`; it echoes +`region_1based` and `requested_length` so the span is checkable. **Always check +the returned length against what the question asked for** before answering — a +sequence of the wrong length is wrong even when every base you kept is right. + + Any question with a **single deterministic numeric/combinatorial answer** must be obtained by **RUNNING code**, never by estimating or doing it in your head. This covers sequence questions (ORF counts, restriction fragments/sizes, GC content, translation) **and** any other exactly-computable question — e.g. **genetics segregation / Mendelian or polyploid gamete ratios, combinatorial probabilities, stoichiometry, dosage/PK arithmetic, counting problems**. Mental arithmetic on these is the #1 avoidable error: the model reliably mis-counts or mis-multiplies. If a question reduces to "enumerate the cases / multiply the probabilities / count the objects", **write a short Python snippet, execute it, and report exactly what it returns** — even when the topic looks like a biology "reasoning" question, if the answer is a definite number, compute it rather than reason it out. Match the question's wording for conventions (which strand; linear vs circular; which cross/segregation model) and **state the convention you used** so the answer is auditable. **Final-answer discipline (avoid "computed right, answered wrong").** After the code returns the value, map it back to the option letters **carefully and explicitly**: quote the computed value, then find the option that matches it exactly (for a set of fragment sizes, match the whole multiset; for a count, match the integer). A surprising number of misses are cases where the computation was correct but the wrong letter was selected — do not let this happen; re-read each option against the computed result before emitting `[ANSWER]`. @@ -219,5 +305,19 @@ Interpretation: report the **exact value the code returns** (ORF count; fragment ## Limitations (honest) - **Key-gated sources**: `DisGeNET_*` and OMIM tools need `DISGENET_API_KEY` / OMIM key. Without a key, fall back to `OpenTargets_*` / `MyDisease_*` (keyless) and state the source used. If no keyless source can answer and the question is database-specific, this is a genuine "Insufficient information" case — say so. -- **Release mismatch**: a tool's snapshot of a database may differ slightly from the exact release a question cites; report the source and version when it matters. +- **Release mismatch**: a tool's snapshot of a database may differ from the exact + release a question cites — and for some quantities the difference is not + slight. Derived scores get recomputed between releases, so the *same gene* can + differ by an order of magnitude. gnomAD pLI, via `gnomad_get_constraint`: + + | gene | gnomAD r4 | gnomAD r2.1 | + |---|---|---| + | APOC2 | 0.046875 | 0.401638 | + | APOC1 | 0.086323 | 0.216848 | + + Where a tool exposes a `dataset`/release parameter, set it to the release the + question names and **say which release you used**. If the question names one + the tool cannot serve, report the release you did use rather than presenting + the number as if it were release-independent — a bare pLI value is ambiguous + by a factor of eight here. - This skill grounds *factual* lookups. For computing over user data files, use the data-analysis router skills instead. -- 2.54.0 From d39e45bd5ef627ed6afbf518e580d99b3cc0ba27 Mon Sep 17 00:00:00 2001 From: promptadmin Date: Mon, 10 Aug 2026 09:57:29 +0000 Subject: [PATCH 2/2] [upstream-sync] skills/tooluniverse-phylogenetics/SKILL.md from mims-harvard/ToolUniverse@8e9110ec [catalogue] --- .../tooluniverse-phylogenetics/SKILL.md | 47 +++++++++++++++++-- 1 file changed, 44 insertions(+), 3 deletions(-) diff --git a/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-phylogenetics/SKILL.md b/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-phylogenetics/SKILL.md index 2eca8acb..39e8f295 100644 --- a/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-phylogenetics/SKILL.md +++ b/upstream/mims-harvard-ToolUniverse/catalogue/skills/tooluniverse-phylogenetics/SKILL.md @@ -1,8 +1,8 @@ --- lineage_type: import -upstream_source: https://github.com/mims-harvard/ToolUniverse/blob/cfd26718/skills/tooluniverse-phylogenetics/SKILL.md -upstream_sha: cfd26718 -imported_at: 2026-08-08 +upstream_source: https://github.com/mims-harvard/ToolUniverse/blob/8e9110ec/skills/tooluniverse-phylogenetics/SKILL.md +upstream_sha: 8e9110ec +imported_at: 2026-08-10 prompt_class: catalogue upstream_changes: accepted name: tooluniverse-phylogenetics @@ -351,6 +351,47 @@ tu run phykit_batch_analysis '{"operation":"gap_percentage","directory":"./align ``` Do NOT run phykit manually in a loop — the tool handles all files and returns correct summary statistics. +**The batch tool is parallel: ~250 trees finish in about 35 seconds.** A per-tree +shell loop takes ~9 minutes for the same work and is the single most common way +these questions end with no answer at all — the run hits its turn or time budget +mid-loop and reports "I'll report when it finishes" instead of a number. If you +find yourself writing `for f in *.treefile`, stop and call the batch tool. + +Supported `function` values include `treeness`, `saturation`, `dvmc`, +`long_branch_score`, `total_tree_length`, `parsimony_informative`, +`treeness_over_rcv` (alias `toverr`). `dvmc` and `long_branch_score` are +covered — you do not need to loop for those. + +**Two-group comparisons (Mann-Whitney U, differences of medians).** Questions +comparing fungi against animals need one batch call per group, then the test on +the two value lists — not a per-tree loop over both groups: + +```bash +tu run phykit_batch_analysis '{"operation":"batch","function":"dvmc","directory":"","extension":".treefile"}' +tu run phykit_batch_analysis '{"operation":"batch","function":"dvmc","directory":"","extension":".treefile"}' +# then scipy.stats.mannwhitneyu(fungi_values, animal_values) +``` + +Ask for `values` in the result when you need the full list for a test; the batch +tool returns them for sets up to 50 and summary statistics always. For larger +sets, compute the statistic from the per-group summaries the tool returns rather +than re-deriving every value by hand. + +### Commit the value you computed + +Two failures in this benchmark came from computing the right number and then +answering a different one: + +- a tree-length ratio computed as **2.1775**, then answered as 1.9 after + re-reading "paired orthologs"; +- an average treeness that listed **19** among the alternatives, then committed 10. + +When a question is ambiguous, compute the reading you judge most literal, state +the alternative in one clause, and **answer with the value you actually +computed**. Do not replace a computed result with a re-derived one at the last +step — if two readings are both defensible, give the computed number first and +name the other, rather than silently switching. + ### PhyKIT column-position cheat sheet (parse output carefully) When parsing PhyKIT stdout for batch metrics, the **column you want** depends on the metric: -- 2.54.0