bioinfo-autopilot

name	bioinfo-autopilot
description	Use when bioinformatics or quantitative biomedical workflows need end-to-end from analysis design to evidence-backed interpretation.

Bioinfo Autopilot

Overview / 概览

Bioinfo Autopilot helps finish bioinformatics work, end-to-end from analysis design to evidence-backed interpretation

Local Skill Routing

Bioinfo Autopilot is the user-facing entry point for bioinformatics execution on this machine. It must not depend on imported catalogs, hidden leaf-skill libraries, or auxiliary catalog directories.

When a task needs narrower guidance:

1. Use first-party local skills first when they fit the task.
   • leo-r-stylefor R coding
2. If no first-party skill is specific enough, rely on primary sources:
   • official manuals
   • official repositories
   • Bioconductor/package documentation
   • method papers when they define the workflow contract
3. Search for the smallest official source that answers the concrete question. Do not load broad catalogs or recreate imported leaf skills as top-level entries.
4. Adapt official guidance to the local project only after the source contract is clear.

When to Use

• The task spans design, implementation, reruns, QC, and final interpretation rather than a one-off command.
• Tool flags, file formats, or output semantics need official-doc verification before editing scripts.
• A workflow has repeated failures, suspicious QC, or technically successful output that may still be scientifically wrong.

Quick Reference

Signal	Required response
Unknown flag, format, or output meaning	Verify the official source before editing or interpreting.
Bioinformatics / code / plotting bug or unexpected behavior	Search official docs first, then search the web for similar cases and validated fixes before editing.
Repeated same-pattern failure	Stop parameter-only nudges and switch hypothesis class.
Exit 0 but QC looks implausible	Refuse completion and trace the earliest broken stage.

Core Rules

1. Verify official docs before changing commands, parameters, formats, or assumptions.
2. Prefer primary sources (official manuals, official repositories, Bioconductor package pages, standards docs).
3. For any bioinformatics, coding, or plotting failure, search for similar cases and solutions before patching: start with official docs/issues/vignettes, then expand to broader web search only if the official source is insufficient.
4. Define expected deliverables, success checks, and restart points before the first run.
5. Run the full workflow end-to-end; do not stop at partial success, warning-heavy output, or silently incomplete files.
6. After every failed run, record the exact failure signal, attempt number, and what changed before the next rerun.
7. If the first full run passes all scientific and technical checks, accept first-pass completion; do not invent extra reruns for ceremony.
8. If two consecutive attempts are only micro-tuning of the same idea, stop and switch to a materially different hypothesis.
9. Escalate verification pressure with each repeat failure; do not relax QC standards just to force a nominal success.
10. Never mutate raw inputs in place; prefer derived files, explicit checkpoints, and reversible edits.
11. Keep outputs structured and report what changed, why, and how validated.
12. When the task is to implement or code a new concept, method, or statistical idea, explain it briefly and clearly first if the user seems unsure, then keep the explanation on the main task.
13. If that explanation would become too complex or uncertain, give a short prompt for a new agent or ChatGPT to help the user understand it there first, then return to the main task.

Official-Docs-First Procedure

1. Identify all tools touched by the workflow.
2. For each tool, open the official docs and verify:
   • Required input fields and formats.
   • Meaning of critical flags and defaults.
   • Output column semantics.
   • Version-specific behaviors.
3. Start with the bundled official-source list, but treat it as representative rather than exhaustive.
4. If a tool is not listed, search the web immediately for the official manual, official repository, official package page, or consortium documentation before editing anything.
5. For technical failures in bioinformatics pipelines, R/Python code, or figure assembly, also search the web for similar reported cases and solutions; prioritize official issues, vignettes, reference manuals, and maintainer-authored discussions.
6. Record links and key constraints before editing scripts.

Documentation Gate

For unfamiliar or unstable plotting/reporting packages, do not start implementation until you have recorded:

• Package version.
• Official vignette/manual/repo link.
• Key function contracts.
• Known limitations.
• A minimal runnable example.

Graphics Workflow Gate

For ggplot2, forestploter, ComplexHeatmap, survminer, and similar plotting/reporting packages:

1. Run the official minimal example first.
2. Search for similar layout/alignment/legend/axis problems in official docs, vignettes, issues, or maintainer discussions before improvising a fix.
3. Make the smallest change needed to reproduce the target layout.
4. Only then connect the code to project data.

Execution Procedure

1. Inspect current scripts/config and dataset schema.
2. Define the intended final artifacts, key QC metrics, and deterministic rerun command before editing anything. For unfamiliar or unstable plotting/reporting packages, post a first-source ledger to the user before the first code edit: which official sources were checked, which version is in scope, which behaviors are doc-confirmed, and which are inferred from source.
3. Apply minimal, targeted edits only after the first-source ledger is posted.
4. Run syntax checks first.
5. Run full pipeline command(s).
6. Tail logs continuously and inspect intermediate artifacts, not just the final exit code.
7. On failure:
   • Capture the exact error text, failing step, attempt number, and affected files.
   • Search official docs plus similar reported cases before patching the code or analysis.
8. If the same failure class repeats, escalate by attempt count:
   • Attempt 2: ban parameter-only nudges; change hypothesis class or inspect raw inputs/source more deeply.
   • Attempt 3: re-read relevant official docs, verify all preconditions, and write down 3 competing root-cause hypotheses before rerunning.
   • Attempt 4+: isolate a minimal failing subset or alternate tool path, compare behaviors, and trace the defect upstream to the earliest corrupted artifact.
   • Never rerun the same failing command unless code, data, environment, or hypothesis changed and that change is explicit.
9. After success, run output QA checks (row counts, required files, key metrics, error summaries) on the intended full workload, not just a toy subset.

Scientific Evidence Chain

Before declaring a bioinformatics result trustworthy, verify all applicable links in the chain:

• Data provenance: raw inputs, genome/reference build, annotation release, sample identifiers, and phenotype/group coding are explicit and consistent.
• Method contract: commands, flags, defaults, and required fields match the official source for the exact tool/version in use.
• Design contract: covariates, contrasts, pairing, batch variables, and inclusion/exclusion rules match the study question rather than an accidental default.
• Diagnostic evidence: standard QC outputs or a justified surrogate check show that the model/data behaved as expected.
• Stage-to-stage integrity: counts of samples, variants, genes, cells, or spots are tracked and unexpected losses are explained.
• Scientific interpretation boundary: the conclusion does not overreach what the surviving data, diagnostics, and sensitivity of the method can support.

If any link in this chain is weak or undocumented, completion is not yet scientific.

Completion Criteria

Declare completion only when all are true:

• Main command exits successfully on the intended workload.
• All expected output files exist and are non-empty where applicable.
• QC/diagnostic summaries are produced.
• Preflight expectations and final observed counts/structures are either consistent or explicitly reconciled.
• Remaining warnings are explained, scoped, and do not invalidate the design contract, diagnostics, or interpretation boundary.
• Re-run is reproducible with same commands.
• No higher-impact unresolved blocker is merely deferred to "next step" without explanation.

Post-Success Challenge

Before saying "done", ask:

• Could this output be technically complete but scientifically wrong?
• Did any sample/variant/gene/cell count collapse unexpectedly between stages?
• Did any build, annotation, covariate, contrast, or grouping assumption remain implicit rather than verified?
• Did any conclusion depend on too few surviving variants/samples/cells to be robust for this method?
• Would a skeptical collaborator be able to rerun this from the reported commands and reach the same files and summary metrics?