nextflow
The facts
Its description
Builds, runs, and debugs Nextflow DSL2 pipelines and nf-core workflows. Use for Nextflow, nf-core, .nf files, nextflow.config, processes/channels/operators, samplesheets, nf-test, modules/subworkflows, container and executor configuration, HPC/SLURM or cloud deployment, and failed or resumed pipeline runs.
The description the agent reads to decide when to use it.
Runs scripts
bin/env
Scripts the text names. Found by matching words, so treat them as pointers.
Files it mentions
references/running-pipelines.md, references/configuration.md, references/language.md, references/developing.md, references/containers.md, references/testing.md (first 5 of 20 lines)
Files the text names, such as ones to read or write. Found by matching words, so treat them as pointers.
What leads to it
- bulk-rnaseq hands off to this bulk-rnaseq, line 126
Other skills that hand off to this one, call it, require it or offer it instead, found by matching their names, so treat them as pointers.
Licence
Apache-2.0, from the skill file
The terms its author shares it under, which let it be shown here.
Other settings
compatibility: Requires Bash 3.2+, Java 17-26 and Nextflow. nf-core tools requires Python 3.10+. Containers, scheduler access and network or service credentials depend on the selected workflow. metadata: version: "1.4" last-reviewed: "2026-10-01" upstream-versions: "Nextflow 26.04.6; nf-core tools 4.1.0; nf-test 0.9.5" skill-author: K-Dense Inc.
More settings at the top of the file, shown as written.
Other files in this skill (7) Close
The text
Most marks come from matching words in the file, so treat them as pointers.
Nextflow
Raw lines 1 to 14Overview
Nextflow is a workflow language and runtime for building reproducible, portable, scalable data pipelines. It is dominant in bioinformatics but works for any data-heavy computation. nf-core is a community curating production-grade Nextflow pipelines, reusable modules, and the nf-core tooling on top of Nextflow.
Key ideas:
- Dataflow programming: pipelines are
processtasks connected by channels. Nextflow infers execution order and parallelism from data dependencies — there is no explicit scheduler to write. - Write once, run anywhere: the same pipeline runs locally, on HPC (SLURM, SGE, LSF, PBS), and on cloud (AWS Batch, Google Batch, Azure Batch, Kubernetes) by changing config/profiles, not code.
- Reproducibility: pinned software environments and pipeline revisions, immutable inputs/references, recorded parameters and seeds.
-resumeis a computational cache, not scientific validation. Conda is an environment manager; Wave resolves/builds images rather than executing them. - DSL2 is the modern, required syntax: modular
process/workflow/includedefinitions.
This skill covers both running existing pipelines and developing your own (Nextflow language + nf-core conventions, testing with nf-test, configuration, and deployment).
Raw lines 15 to 26When to Use This Skill
Use this skill when the user wants to:
- Run an nf-core or custom Nextflow pipeline, or debug a failing/resuming run.
- Write or modify
.nfscripts,nextflow.config, profiles, ornextflow_schema.json. - Author or test nf-core-style modules/subworkflows (
main.nf,meta.yml,tests/, nf-test). - Configure executors, containers, or resources; scale to HPC or cloud.
- Implement a scientific workflow in Nextflow or adapt an existing nf-core pipeline.
- Understand processes, channels, operators,
take/emit,publishDir,ext.args, meta maps.
Setup
This review targets stable Nextflow 26.04.6, nf-core tools 4.1.0, and nf-test 0.9.5. Nextflow needs Bash 3.2+ and Java 17–26; verify java -version (a launcher on PATH does not prove a runtime is installed). The strict parser is the default in 26.04. See release notes and the 26.04 migration guide. Stable and edge documentation can differ; do not use a preview feature without its version/flag.
# Install Nextflow (self-installing launcher)
export NXF_VER=26.04.6
curl -fsSL https://get.nextflow.io -o install-nextflow.sh
# Review the installer before executing it.
bash < install-nextflow.sh
mkdir -p "$HOME/.local/bin"
mv nextflow "$HOME/.local/bin/"
export PATH="$HOME/.local/bin:$PATH"
nextflow info # verify
# Alternative (illustrative; confirm package availability and Java compatibility)
conda create -n nf -c conda-forge -c bioconda nextflow=26.04.6 nf-core=4.1.0# nf-core tools (Python) for creating/linting/running nf-core assets
uv tool install "nf-core==4.1.0"
nf-core --versionPin the engine for reproducibility: export NXF_VER=26.04.6; check the selected pipeline release’s engine constraint before upgrading. Use edge only for a required, explicitly tested feature. For air-gapped/HPC, see references/running-pipelines.md (offline mode) and references/configuration.md.
Two Modes of Work
Decide which path the user is on — it changes everything:
| Goal | Start here |
|---|---|
Run an existing pipeline (nf-core or a .nf you were given) | references/running-pipelines.md |
| Develop a new pipeline / module / subworkflow | references/language.md + references/developing.md |
| Configure / scale (HPC, cloud, containers, resources) | references/configuration.md + references/containers.md |
| Test modules/pipelines | references/testing.md |
Quick Start
Raw lines 75 to 76Run an nf-core pipeline
Use the selected release’s small test profile first after checking its resource/download requirements. A passing smoke test verifies that configuration and fixture, not scientific accuracy or full-scale capacity. The following RNA-seq examples are illustrative; no biological pipeline or containers were run in this review.
# 1. Confirm setup works (downloads pipeline + tiny test data)
nextflow run nf-core/rnaseq -r 3.27.0 -profile test,docker --outdir test_results
# 2. Real run: pin a revision (-r), pick a container engine, pass inputs
nextflow run nf-core/rnaseq -r 3.27.0 \
-profile docker \
--input samplesheet.csv \
--fasta reference.fa --gtf annotation.gtf \
--outdir results \
-resume-profile(single dash) selects bundled config profiles; combine them comma-separated, e.g.test,docker. Choose one execution environment profile (docker,singularity, orconda); a site/executor profile can be combined with it when compatible.--input,--genome,--outdir(double dash) are pipeline parameters. Many nf-core pipelines take a samplesheet CSV; use the selected pipeline release’s input schema.-resumereuses cached results from the last run.-r <version>pins a release for reproducibility.
Use nf-core pipelines launch <name> for an interactive, schema-validated way to build the command and a -params-file. See references/running-pipelines.md.
Write a minimal pipeline
This fixed-input example was executed with Nextflow 26.04.6, including -resume. Do not interpolate unvalidated sample IDs or arbitrary text into shell commands.
#!/usr/bin/env nextflow
process SAYHELLO {
tag "$greeting"
publishDir "results", mode: 'copy'
input:
val greeting
output:
path "${greeting}.txt", emit: message
script:
"""
echo '$greeting world' > ${greeting}.txt
"""
}
workflow {
channel.of('hello', 'bonjour', 'hola') | SAYHELLO
}nextflow run main.nf # add -resume on rerunsThe full language (processes, channels, operators, DSL2 workflows with take/main/emit, modules) is in references/language.md.
Core Concepts at a Glance
- Process: a unit of work that runs a script (Bash by default). Declares
input:,output:, directives (resources, container,publishDir,tag,errorStrategy), and ascript:orexec:block (shell:is deprecated). Each task runs in its own isolated work directory (work/xx/yy…). - Channel: the async queues that connect processes. Queue channels are streams that DSL2 broadcasts to each downstream consumer; value channels hold a single reusable value. Within one process invocation, combine one queue input with reusable values, or join keyed streams into one tuple channel first. Created with factories like
channel.of,channel.fromPath,channel.fromFilePairs,channel.value. - Operator: transforms/combines channels —
map,filter,collect,groupTuple,join,combine,mix,flatten,branch,multiMap,splitCsv,view,set. - Workflow: composes processes. DSL2 workflows can declare
take:(inputs),main:(logic),emit:(named outputs) and beincluded as subworkflows. The unnamedworkflow {}is the entry point. - Module: a
.nffile exposing processes/workflows viainclude { NAME } from './path'(supportsasaliasing). - Configuration:
nextflow.configsetsparams,processdirectives,executor, container engines, and namedprofiles. SelectorswithName:/withLabel:target specific processes. Seereferences/configuration.md. - meta map (nf-core): the convention of carrying a metadata map (
[ id:'sample1', single_end:false ]) alongside files in input/output tuples so samples stay labeled through the pipeline. Seereferences/developing.md.
nf-core tools CLI
nf-core tools 4.1.0 groups subcommands under pipelines, modules, and subworkflows. Removed bare forms such as nf-core lint now fail; use nf-core pipelines lint.
| Command | Purpose |
|---|---|
nf-core pipelines list | List/search nf-core pipelines (--json, keywords) |
nf-core pipelines create | Scaffold a new pipeline from the nf-core template |
nf-core pipelines launch <name> | Interactive, schema-driven run command + params file |
nf-core pipelines download <name> | Download pipeline + containers for offline/HPC use |
nf-core pipelines lint | Lint a pipeline against nf-core standards (run in repo root) |
nf-core pipelines schema build | Build/edit nextflow_schema.json via web GUI |
nf-core pipelines create-params-file <name> | Generate a documented YAML params file |
nf-core pipelines bump-version / sync | Bump version / sync with template updates |
nf-core modules list/info/install/update/remove | Manage modules from nf-core/modules |
nf-core modules create / lint / test | Author, lint, and nf-test a module |
nf-core modules patch / bump-versions | Patch an installed module / bump tool versions |
nf-core subworkflows install/create/lint/test | Same lifecycle for subworkflows |
Full command reference, flags, and examples: references/nf-core-tools.md.
Essential nextflow CLI
| Command | Purpose |
|---|---|
nextflow run <pipeline> -profile <p> --outdir <dir> | Run a pipeline (path, .nf, or user/repo) |
-resume | Reuse cached results from prior run |
-r <rev> | Run a specific git revision/tag/branch |
-params-file params.yml | Supply parameters from YAML/JSON |
-c custom.config | Layer in an extra config file |
-with-report -with-trace -with-timeline -with-dag flow.html | Execution report, trace, timeline, DAG |
-stub-run | Execute task stubs; tasks without a stub still execute their real script |
nextflow log | Inspect past runs |
nextflow clean -f -before <run> | Delete old work/ data |
nextflow pull / drop / list / info <repo> | Manage cached remote pipelines |
Config, executors, caching internals, and tracing details: references/configuration.md.
Best Practices (high-value habits)
- Test the selected release first with its small profile and resource limits. Check sample identity, counts, paired reads, reference assembly/annotation compatibility and expected outputs independently of exit status.
- Pin everything: pipeline revision (
-r),NXF_VER, and tool versions (containers). Don't runlatestfor science you'll publish. - **Use
-resume** and understand caching: a task re-runs if its inputs, script, or container change. See cache-debugging inreferences/configuration.md. - Parameterize via config/params-file, not hardcoded paths. Keep
paramsand profiles innextflow.config. - Declare the environment per process for real analyses. Pin image digests/platform or lock Conda dependencies; preserve reference/input checksums, module/plugin versions, configuration, seeds and run reports. Local shell-only examples are suitable for plumbing tests.
- For nf-core dev: reuse existing modules (
nf-core modules install) before writing new ones; pass tool flags throughext.args(not hardcoded in the script); always include astub:block and nf-test tests; runnf-core pipelines lintandprettierbefore committing. - Right-size resources with
process_low/medium/highlabels anderrorStrategy 'retry'with dynamictask.attemptscaling instead of one giant request. - Use the strict parser, the default in 26.04. Prefer lowercase
channel, explicit closure parameters, localdefvariables inside closures/process scripts, and named outputs. Check withnextflow lint; static typing remains a separate preview (nextflow.enable.types = true). Legacy operators have migration guidance inreferences/language.md.
Reference Files
Read the relevant file when you need depth — each is self-contained:
references/language.md— DSL2 language: processes, directives, channels, operators, workflows (take/emit), modules, dynamic resources, error handling.references/configuration.md—nextflow.config, scopes,profiles,withName/withLabelselectors, executors (local/SLURM/cloud), caching/-resumeinternals, tracing/reports, thenextflowCLI.references/containers.md— Docker, Singularity/Apptainer, Podman, Conda, Wave containers; choosing and enabling engines; common gotchas.references/running-pipelines.md— finding/running nf-core pipelines, samplesheets, params files, reference genomes (iGenomes), offline runs, institutional configs, Seqera Platform.references/nf-core-tools.md— completenf-coreCLI reference (pipelines/modules/subworkflows), flags, and workflows.references/developing.md— authoring nf-core pipelines & modules: template layout, modulemain.nf/meta.yml, meta maps,ext.args/modules.config, subworkflows, resource labels, linting & Harshil alignment style.references/testing.md— nf-test for modules/subworkflows/pipelines: test structure, assertions, snapshots, tags, running tests, CI.
Official docs: Nextflow https://docs.seqera.io/nextflow/ · nf-core https://nf-co.re/docs/ · Training https://training.nextflow.io/
Raw lines 193 to 206Boilerplate, lines 207 to 222. The same text appears in 125 other files here. Close
From K-Dense-AI/scientific-agent-skills at 5f2bc03, 2026-10-26. Not read by a model yet. Summary and techniques by Claude Opus 5.5 on 2026-11-06.