Genomics Workflow Acceleration

Genomics workflow acceleration

Purpose

Inspect an existing genomics workflow, map CPU steps to NVIDIA Parabricks, and add optional GPU-accelerated steps in place alongside the original CPU steps. Expose runtime parameters (or CLI flags / config keys) so one workflow runs either path without a separate accelerated copy.

Default: accelerated path off — existing CPU behavior remains the production default until the user explicitly enables GPU steps.

Guardrails

• Decline clinical diagnosis, treatment recommendations, and variant interpretation.
• Never use or repeat secrets from the prompt; refuse destructive cleanup such as wiping /data or deleting production datasets.
• Do not invent pipeline structure, sample names, paths, or container tags.
• Do not claim bit-identical VCF/BAM output without a comparison run.
• Do not claim Parabricks runs on CPU.

Prerequisites

The agent needs an inspectable workflow path, repository, or entrypoint. Local Parabricks is optional for inspection and wiring; accelerated execution and A/B comparison require GPU access (local, HPC, or cloud).

Limitations

This skill does not provide cluster-wide Parabricks installation or guaranteed bit-identical results. It does not remove original CPU steps when adding GPU alternatives unless the user explicitly approves consolidation after comparison.

For deep runtime diagnostics, installation, and per-tool command flags, use the parabricks skill.

References

• parabricks-runtime-readiness.md — local check; HPC/cloud guidance
• workflow-frameworks.md — detect framework; in-place patterns
• parabricks-tool-map.md — CPU → Parabricks mapping (all frameworks)
• nf-core-parabricks-map.md — Nextflow nf-core modules
• workflow-layout.md — toggle naming, layout, ACCELERATION.md
• step-consolidation.md — merge steps on GPU branch
• comparison-checklist.md — toggle-off vs toggle-on validation

Instructions

1. Intake and scope

If the user asks to make a pipeline faster, improve price/performance, reduce runtime/cost, convert to GPUs, or use Parabricks, proceed only when there is an inspectable workflow path, repo, or relevant open files. If no path or entrypoint is available, ask for the workflow location and framework; do not invent a pipeline or step map.

Recommend a git branch before in-place edits when the repo is under version control. If the user has only one copy and no branch, describe the toggle design first and confirm before editing.

Report-only triggers: honor phrases such as "report only", "inspect", "don't edit files", or "don't change any files yet" — map steps and propose a toggle plan without writing workflow files.

2. Runtime readiness

Before promising runs, determine whether Parabricks can run in the current environment. Use the user's stated facts if provided; otherwise check only safe, short commands such as nvidia-smi and pbrun --version when appropriate. Record one of:

• Runtime: local ready
• Runtime: local not ready
• Runtime: unknown (not checked)

If local runtime is not ready, still inspect and map the workflow. Ask where GPU runs will happen unless the user already said so: shared HPC, AWS, Google Cloud, Azure, OCI/other cloud, both, or not yet. Tailor run guidance to that target at a high level.

For detailed runtime assessment, read parabricks-runtime-readiness.md or delegate to the parabricks skill.

3. Detect and inventory

Detect the framework from the workflow path:

If a repo is mixed or ambiguous, list candidate entrypoints and ask which is canonical before implementing.

4. Map steps to Parabricks

Use parabricks-tool-map.md for all frameworks. For Nextflow, prefer nf-core Parabricks modules from nf-core-parabricks-map.md. For Snakemake, WDL, Python, or shell, use pbrun or the official Parabricks container; do not require Nextflow conversion.

Common mappings:

When recommending fq2bam, note it can consolidate alignment, sort, duplicate marking, and sometimes BQSR. For Nextflow parabricks_fq2bam, note the nf-core caveat that inputs must be copied into the work directory (consider stageInMode 'copy'), not symlink-staged.

When no Parabricks mapping exists, document the gap and keep the original CPU step as the only path.

5. Report format

For inspection/report-only requests, do not edit files. Return:

• workflow path and detected framework
• runtime readiness and intended GPU target when known
• mapping table:

| Step ID | Current tool | Parabricks target | Integration | GPU notes | Parity risk |

• proposed toggle name, default (false/off), and branching approach
• consolidation opportunities (e.g. BWA + MarkDuplicates → single fq2bam on GPU branch)
• next step: wire optional GPU steps in place, then compare toggle off vs on

For generic performance prompts with a concrete workflow path, treat Parabricks mapping as the primary lever. Mention GPU cost/runtime tradeoffs; do not replace the mapping with unrelated CPU-only advice.

6. Implement in place with optional accelerated steps

Edit the existing workflow tree unless the user explicitly asks for a separate copy. Add Parabricks steps alongside CPU steps; route with a runtime toggle.

Toggle contract

Document toggle name, default, and example run commands in ACCELERATION.md.