genomics-workflow-acceleration

Files (12)

• BENCHMARK.md
• SKILL.md
• evals.json · evals/
• comparison-checklist.md · references/
• nf-core-parabricks-map.md · references/
• parabricks-runtime-readiness.md · references/
• parabricks-tool-map.md · references/
• step-consolidation.md · references/
• workflow-frameworks.md · references/
• workflow-layout.md · references/
• skill-card.md
• skill.oms.sig

SKILL.md (first lines)

# 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](references/parabricks-runtime-readiness.md) — local check; HPC/cloud guidance
- [workflow-frameworks.md](references/workflow-frameworks.md) — detect framework; in-place patterns
- [parabricks-tool-map.md](references/parabricks-tool-map.md) — CPU → Parabricks mapping (all frameworks)
- [nf-core-parabricks-map.md](references/nf-core-parabricks-map.md) — Nextflow nf-core modules
- [workflow-layout.md](references/workflow-layout.md) — toggle naming, layout, `ACCELERATION.md`
- [step-consolidation.md](references/step-consolidation.md) — merge steps on GPU branch
- [comparison-checklist.md](references/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](references/parabricks-runtime-readiness.md) or
delegate to the `parabricks` skill.

### 3. Detect and inventory

Detect the framework from the workflow path:

| Framework | Markers | Inventory |
|-----------|---------|-----------|
| Nextflow | `main.nf`, `nextflow.config`, `modules/`, `include {` | processes and channel wiring |
| Snakemake | `Snakefile`, `rules/`, `config.yaml` | rules, shell/script blocks, resources |
| WDL | `*.wdl`, `workflow {`, `task`, `call` | tasks, commands, runtime blocks |
| Python | `*.py`, `pyproject.toml`, CLI entrypoints | functions and subprocess/shell calls |

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](references/parabricks-tool-map.md) for all
frameworks. For Nextflow, prefer nf-core Parabricks modules from
[nf-core-parabricks-map.md](references/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:

| Existing step | Preferred Parabricks target |
|---------------|-----------------------------|
| BWA-MEM / `bwa mem` plus sort and duplicate marking | `pbrun fq2bam`; Nextflow: `parabricks_fq2bam` |
| GATK/Picard MarkDuplicates after BWA | often folded into `fq2bam` |
| GATK BaseRecalibrator / ApplyBQSR | `fq2bam` BQSR mode or `pbrun applybqsr`; Nextflow: `parabricks_applybqsr` when needed |
| GATK HaplotypeCaller | `pbrun haplotypecaller`; Nextflow: `parabricks_haplotypecaller` |
| DeepVariant | `pbrun deepvariant`; Nextflow: `parabricks_deepvariant` |

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

From NVIDIA/skills, CC-BY-4.0 AND Apache-2.0.

More from NVIDIA/skills