ToolUniverse Router

FIRST ACTION: Route to a Specialized Skill

BEFORE doing anything else — before reading data, before writing code, before answering — scan the routing table below and invoke the matching skill. The specialized skill contains critical domain conventions that you will get wrong without loading.

How to route:

1. Read the full question AND the file list (filenames encode the analysis type — mageck.xlsx → CRISPR screen, DM.csv/AE.csv → clinical trial AE, .vcf → variant, .h5ad → single-cell, counts.csv+meta.csv → RNA-seq DE, .faa+.treefile → phylogenetics, executed.ipynb → authoritative analysis already ran)
2. Find the matching keyword row in the Routing Table
3. Call Skill(skill="<skill-name>") immediately
4. Follow the loaded skill's instructions to answer the question

If no keyword matches but filenames indicate a domain → still route based on filename signals. Filenames are authoritative domain evidence even when the question prose is generic.

If no signal matches → use general strategies below.

DO NOT skip routing. Even if you think you know the answer, the skill has conventions (e.g., which denominator to use, which R function, which column to read) that differ from defaults.

Critical Analysis Conventions

RULE ZERO: Use the authoritative pipeline if one ships with the data

Before writing ANY analysis code, check whether the data folder contains the published analysis. Two common forms:

1. Executed notebook (_executed.ipynb, .ipynb) — the analysis has already run with the exact package versions, filters, and thresholds behind the reference answers. Reimplementing with pydeseq2/scanpy/gseapy produces different numbers. Read the outputs directly:

``bash tu run readexecutednotebook '{"data_folder":"/path/to/data","search":"<keyword>"}' ``

search can be comma-separated terms (e.g., "upregulated,log2FoldChange") or a regex. The tool returns the matching cells' source + printed outputs so you can cite the published value instead of recomputing.

1. Executable script (run.py, analysis.R, find.R, *.Rmd) — execute and report:

``bash ls /path/to/data/folder cd /path/to/data && python3 run_*.py # or Rscript analysis.R ``

Canonical vs scratch scripts: when a folder has many .R/.py files, prefer ones with canonical names (analysis.R, main.R, run.R, run<questiontopic>.R) over scratch-named ones (try.R, check.R, inspect.R, verify.R, _v2.R, 2.R, *3.R). Scratch-named scripts are usually leftovers from prior agent attempts that may not have converged on the published answer — treat their outputs as advisory, not authoritative.

Only write your own analysis code when no authoritative pipeline exists in the data folder. When one does exist, your job is to execute/read it and report — not to reimplement.

RULE ZERO sub-rule — Cite-the-cell-output: If the notebook has a cell whose output IS the answer to the question (e.g., len(sigs) = 197, mean p-value: 0.0254, top hit: GENE_X), copy that output value directly. Do NOT recompute with your own filters. The notebook may apply slightly-different filters than the question text describes (e.g., the question lists padj<0.05, |LFC|>0.5, baseMean>10 but the notebook's filter line has & (baseMean>=10) commented out). The published answer is the notebook's output — even if the question's filter list slightly differs from what the notebook actually applied. The benchmark's GT comes from the notebook's actual computation, not from re-applying the question's literal filter list. Trust the notebook's published number when it directly answers the question.

RULE ONE: Use the bundled skill scripts for recurring analysis patterns

Before writing your own analysis code, check these ready-made scripts in the plugin. They encode the correct conventions and save re-deriving them:

Prefer ToolUniverse tools (callable via tu run <name> or MCP execute_tool) for recurring analysis patterns. They encode the correct conventions:

Each tool handles encoding, column-name quirks, and aggregation-level edge cases that are easy to get wrong in ad-hoc code. Find more tools via tu find "<keyword>" or MCP find_tools.

Brief reminders (one-line)

These are short pointers. The full conventions, anti-pattern examples, and code snippets live in the matching sub-skill — load it via the routing table for the details.

1. Clinical trial AE severity (chi-square OR ordinal/logistic regression): use ALL AE records, max(AESEV) per subject, do NOT filter by AEPT — even when the question names a specific condition like "COVID-19 severity" or "infection severity", AESEV IS the universal outcome, not a subset filter. See tooluniverse-statistical-modeling.
2. Variant counting / fractions (synonymous %, missense %, "fraction of X variants", etc.): denominator is the CODING subset only (synonymous + missense + spliceregion + stopgained/lost + startlost + frameshift + inframeins/del). EXCLUDE intron, intergenic, UTR, splicedonor/acceptor, regulatory, noncoding. The CODING-only denominator applies even when the question doesn't say "coding" explicitly — use codingvariantfraction tool. See tooluniverse-variant-analysis.
3. DESeq2 library: match the authoritative script if present; otherwise prefer R DESeq2 — see tooluniverse-rnaseq-deseq2. When reading the analyst's filter line, only apply filters BEFORE the # comment — do NOT add filters from commented-out code (e.g., # & (baseMean>=10) is OFF, do not include).
4. Per-feature stat (ANOVA F, median LFC): run per-gene then summarize, NEVER pool/sum-then-ratio — see tooluniverse-statistical-modeling.
5. Spline models: use R ns() via Rscript — see tooluniverse-statistical-modeling.
6. PhyKIT saturation: use column 2 (1-slope), not column 1 (slope) — see tooluniverse-phylogenetics.
7. "Also DE in X": simple intersection A ∩ B — see tooluniverse-rnaseq-deseq2.
8. Ratio "between A and B": ALWAYS state BOTH A/B = X AND B/A = 1/X in the final answer. English "ratio between A and B" is direction-ambiguous; reporting both ensures the correct value is in your response. Example output: "Ratio (W to 1) = 1.52, equivalently (1 to W) = 0.66".
9. Units — percentage vs proportion vs ratio: read the question's noun. "percentage" or "percent" → report on 0-100 scale (e.g. 29, not 0.29). "proportion", "fraction", or "ratio" → report as decimal (e.g. 0.29). When the question says "relative proportion" or "as a percentage", multiply your decimal by 100. State both forms when there is any ambiguity (e.g. "0.29 (= 29%)").

These reminders are for fast pattern recognition during routing. Detailed ❌ WRONG / ✅ RIGHT examples and sanity heuristics are in the sub-skill bodies — invoke the skill via the Routing Table to load them.

Routing Table

1. Data Retrieval

2. Research & Profiling

3. Clinical Decision Support

4. Discovery & Design

5. Genomics & Variant Analysis

6. Systems & Network Analysis

7. Screening & Functional Genomics

8. Clinical Trials & Study Design

9. Organism & Evolution

10. Specialized Biology

11. Problem-Solving & Computation

12. Infrastructure & Setup

Tie-Breaking Rules

1. Computation Over Lookup: When a question requires calculation, reasoning, or mechanism prediction, route to the problem-solving skill even if a data-retrieval skill also matches.

- "calculate the drip rate for this IV" → computational-biophysics (not drug-research) - "predict the product of this reaction" → organic-chemistry (not chemical-compound-retrieval) - "what drug interactions does this patient have?" → drug-drug-interaction (clinical reasoning)

1. Domain Over Setup: When "how do I", "help me", "explain", or "what is" co-occurs with a domain entity (drug, gene, protein, disease, variant, pathway name), route to the domain skill, NOT setup.

- "how do I find interactions for TP53?" → protein-interactions - "help me research metformin" → drug-research - "what is EGFR?" → target-research - Only route to setup when NO domain entity present ("how do I use this?")

1. Specificity Rule: More specific beats general.

- "cancer treatment" → precision-oncology (not disease-research)

1. Evaluation Intent Rule: Route requests to review existing/current work to

tooluniverse-self-review, but do not route requests to create or run an eval suite, grader, test, or benchmark there. Those are implementation tasks. Within self-review, plain "eval" is qualitative; scoring requires an explicit score/grade/points request.

1. Data Type Rule: "get/retrieve/fetch" → retrieval skills.

- "get compound structure" → chemical-compound-retrieval (not drug-research)

1. Still ambiguous: Ask user with AskUserQuestion.

When to Use General Strategies

Only when no specialized skill matches:

• Meta-questions about ToolUniverse itself (no domain entity)
• Custom workflows combining multiple skills
• User explicitly says "don't use specialized skills"

WARNING: "how do I find interactions for TP53?" is NOT a meta-question — route to protein-interactions.

When using general strategies, load [references/general-strategies.md](references/general-strategies.md) and execute them (run actual queries, don't just describe).

Problem-Solving Mode

Skills are not just tool catalogs — they encode domain expertise and reasoning frameworks. When a question requires reasoning, computation, or clinical judgment (not just data lookup), route to the appropriate problem-solving skill.

When to use Problem-Solving Mode

• Question requires step-by-step calculation (dosing, dilution, decay, stoichiometry) → tooluniverse-computational-biophysics
• Question requires reaction mechanism reasoning (predict products, NMR interpretation, stereochemistry) → tooluniverse-organic-chemistry
• Question requires clinical decision-making (differential diagnosis, drug interactions, treatment selection) → route to the relevant clinical skill
• Question requires data lookup → use Quick Lookup Mode below

Key principle

Think first, then look up. Many scientific problems require reasoning frameworks + computation, not just database queries. Skills should help you SOLVE problems, not just find data.

Bundled Scripts (cross-skill reference)

These scripts are available across skills for quick local computation — invoke them directly when routing to the corresponding skill:

Quick Lookup Mode

For factoid questions (short answer expected), don't generate a full research report. Instead:

1. Route to the appropriate skill
2. Make 1-3 targeted tool calls
3. Return the specific answer

Examples:

• "How many cysteine residues in [protein]?" → UniProt sequence lookup → count residues
• "What drug interacts with [gene]?" → ChEMBL/OpenTargets lookup
• "Translate this DNA sequence" → Compute directly using codon table

Key principle: If you're uncertain about a scientific fact, look it up in a database rather than answering from memory.

Routing Examples

Clear match: "comprehensive research report on breast cancer" → Skill(skill="tooluniverse-disease-research", args="breast cancer")

Factoid lookup: "How many cysteine residues in GABAAρ1 TM3-TM4 linker?" → Skill(skill="tooluniverse-sequence-analysis") → UniProt lookup → count

Ambiguous: "Tell me about aspirin" → AskUserQuestion: drug profile, safety, chemical data, or repurposing?

No match: "How can I find all tools related to proteomics?" → General strategies: run find_tools queries

Domain + setup keyword: "help me understand BRCA1 variants" → Skill(skill="tooluniverse-variant-interpretation", args="BRCA1")

General Protocols (apply after routing)

• Look up, don't guess: Use ToolUniverse tools to verify facts before answering.
• Compute, don't estimate: Write and run Python/R code for any calculation.
• Analyze, don't just retrieve: For data analysis tasks, execute code and report results.
• Trust tools over memory: If a tool result disagrees with your knowledge, trust the tool.