[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74Z39Y41WDEV02T7FKC4ZAF":3,"skill-same:01M74Z39Y41WDEV02T7FKC4ZAF":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":34,"ownerHtmlUrl":35,"ownerBlogUrl":36,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M74Z39Y41WDEV02T7FKC4ZAF","nextflow",null,"Build, run, and debug Nextflow data pipelines and nf-core workflows end to end. Use whenever the user mentions Nextflow, nf-core, .nf files, nextflow.config, DSL2, processes\u002Fchannels\u002Foperators, samplesheets, or wants to run a community pipeline (e.g. nf-core\u002Frnaseq, nf-core\u002Fsarek), write or test a module\u002Fsubworkflow with nf-test, configure executors\u002Fcontainers (Docker, Singularity\u002FApptainer, Conda, Wave), scale a workflow to HPC\u002FSLURM or cloud (AWS Batch, Google Batch, Azure, Kubernetes), or debug a failed\u002F-resume run. Make sure to use this skill for any reproducible scientific\u002Fbioinformatics workflow work even if the user does not say the word \"Nextflow\", and for authoring nf-core-compliant pipelines, modules, configs, and linting.","KalarisLabs\u002Fresearch-agent-skills","KalarisLabs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F300878568?v=4","01M74Y7MT23GXXC56VM6TVSXZY","Kalarislabs","01M74Y7MTQM9REXZX4SNXWX95C",132,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: nextflow\ndescription: Build, run, and debug Nextflow data pipelines and nf-core workflows end to end. Use whenever the user mentions Nextflow, nf-core, .nf files, nextflow.config, DSL2, processes\u002Fchannels\u002Foperators, samplesheets, or wants to run a community pipeline (e.g. nf-core\u002Frnaseq, nf-core\u002Fsarek), write or test a module\u002Fsubworkflow with nf-test, configure executors\u002Fcontainers (Docker, Singularity\u002FApptainer, Conda, Wave), scale a workflow to HPC\u002FSLURM or cloud (AWS Batch, Google Batch, Azure, Kubernetes), or debug a failed\u002F-resume run. Make sure to use this skill for any reproducible scientific\u002Fbioinformatics workflow work even if the user does not say the word \"Nextflow\", and for authoring nf-core-compliant pipelines, modules, configs, and linting.\nlicense: Apache-2.0\nmetadata:\n  version: '1.2'\n  category: life-sciences\n  maintainer: Kalaris Labs\n  tags: Nextflow, nf-core, bioinformatics pipelines, workflow management, genomics\n---\n\n# Nextflow\n\n## Overview\n\nNextflow 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.\n\nKey ideas:\n- **Dataflow programming**: pipelines are `process` tasks connected by **channels**. Nextflow infers execution order and parallelism from data dependencies — there is no explicit scheduler to write.\n- **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\u002Fprofiles, not code.\n- **Reproducibility**: per-task containers (Docker\u002FSingularity\u002FApptainer\u002FConda\u002FWave) + `-resume` caching + pinned pipeline revisions.\n- **DSL2** is the modern, required syntax: modular `process`\u002F`workflow`\u002F`include` definitions.\n\nThis skill covers both **running** existing pipelines and **developing** your own (Nextflow language + nf-core conventions, testing with nf-test, configuration, and deployment).\n\n## When to Use This Skill\n\nUse this skill when the user wants to:\n- Run an nf-core or custom Nextflow pipeline, or debug a failing\u002Fresuming run.\n- Write or modify `.nf` scripts, `nextflow.config`, profiles, or `nextflow_schema.json`.\n- Author or test nf-core-style modules\u002Fsubworkflows (`main.nf`, `meta.yml`, `tests\u002F`, nf-test).\n- Configure executors, containers, or resources; scale to HPC or cloud.\n- Build a reproducible scientific\u002Fbioinformatics workflow (even if \"Nextflow\" is not named).\n- Understand processes, channels, operators, `take`\u002F`emit`, `publishDir`, `ext.args`, meta maps.\n\n## Setup\n\nNextflow needs **Bash** and **Java 17 or newer** (17–25 supported). Verify with `java -version`.\n\n```bash\n# Install Nextflow (self-contained launcher)\ncurl -s https:\u002F\u002Fget.nextflow.io | bash      # creates .\u002Fnextflow\nsudo mv nextflow \u002Fusr\u002Flocal\u002Fbin\u002F             # put on PATH\nnextflow info                                # verify\n\n# Or via conda\u002Fbioconda (also gets a managed Java)\nconda create -n nf -c bioconda -c conda-forge nextflow nf-core\n```\n\n```bash\n# nf-core tools (Python) for creating\u002Flinting\u002Frunning nf-core assets\nuv pip install nf-core            # or: conda install -c bioconda nf-core\nnf-core --version\n```\n\nPin the engine for reproducibility: `export NXF_VER=24.10.0` (use an [edge] release only if needed). For air-gapped\u002FHPC, see `references\u002Frunning-pipelines.md` (offline mode) and `references\u002Fconfiguration.md`.\n\n## Two Modes of Work\n\nDecide which path the user is on — it changes everything:\n\n| Goal | Start here |\n|------|-----------|\n| **Run** an existing pipeline (nf-core or a `.nf` you were given) | `references\u002Frunning-pipelines.md` |\n| **Develop** a new pipeline \u002F module \u002F subworkflow | `references\u002Flanguage.md` + `references\u002Fdeveloping.md` |\n| **Configure \u002F scale** (HPC, cloud, containers, resources) | `references\u002Fconfiguration.md` + `references\u002Fcontainers.md` |\n| **Test** modules\u002Fpipelines | `references\u002Ftesting.md` |\n\n## Quick Start\n\n### Run an nf-core pipeline\n\nAlways smoke-test with the bundled `test` profile first; it uses tiny data and proves your environment works.\n\n```bash\n# 1. Confirm setup works (downloads pipeline + tiny test data)\nnextflow run nf-core\u002Frnaseq -profile test,docker --outdir results\n\n# 2. Real run: pin a revision (-r), pick a container engine, pass inputs\nnextflow run nf-core\u002Frnaseq -r 3.14.0 \\\n  -profile docker \\\n  --input samplesheet.csv \\\n  --genome GRCh38 \\\n  --outdir results \\\n  -resume\n```\n\n- `-profile` (single dash) selects bundled config profiles; **combine** them comma-separated, e.g. `test,docker`. Container\u002Finfra profiles (`docker`, `singularity`, `conda`) are mutually exclusive — pick one.\n- `--input`, `--genome`, `--outdir` (double dash) are **pipeline** parameters. nf-core pipelines take a **samplesheet CSV**, not loose files.\n- `-resume` reuses cached results from the last run. `-r \u003Cversion>` pins a release for reproducibility.\n\nUse `nf-core pipelines launch \u003Cname>` for an interactive, schema-validated way to build the command and a `-params-file`. See `references\u002Frunning-pipelines.md`.\n\n### Write a minimal pipeline\n\n```nextflow\n#!\u002Fusr\u002Fbin\u002Fenv nextflow\n\nprocess SAYHELLO {\n    tag \"$greeting\"\n    publishDir \"results\", mode: 'copy'\n\n    input:\n    val greeting\n\n    output:\n    path \"${greeting}.txt\"\n\n    script:\n    \"\"\"\n    echo '$greeting world' > ${greeting}.txt\n    \"\"\"\n}\n\nworkflow {\n    channel.of('hello', 'bonjour', 'hola') | SAYHELLO\n}\n```\n\n```bash\nnextflow run main.nf            # add -resume on reruns\n```\n\nThe full language (processes, channels, operators, DSL2 workflows with `take`\u002F`main`\u002F`emit`, modules) is in `references\u002Flanguage.md`.\n\n## Core Concepts at a Glance\n\n- **Process**: a unit of work that runs a script (Bash by default). Declares `input:`, `output:`, optional `directives` (resources, container, `publishDir`, `tag`, `errorStrategy`), and a `script:`\u002F`shell:`\u002F`exec:` block. Each task runs in its own isolated work directory (`work\u002Fxx\u002Fyy…`).\n- **Channel**: the async queues that connect processes. **Queue channels** are consumable streams; **value channels** hold a single reusable value. Created with factories like `channel.of`, `channel.fromPath`, `channel.fromFilePairs`, `channel.value`.\n- **Operator**: transforms\u002Fcombines channels — `map`, `filter`, `collect`, `groupTuple`, `join`, `combine`, `mix`, `flatten`, `branch`, `multiMap`, `splitCsv`, `view`, `set`.\n- **Workflow**: composes processes. DSL2 workflows can declare `take:` (inputs), `main:` (logic), `emit:` (named outputs) and be `include`d as subworkflows. The unnamed `workflow {}` is the entry point.\n- **Module**: a `.nf` file exposing processes\u002Fworkflows via `include { NAME } from '.\u002Fpath'` (supports `as` aliasing).\n- **Configuration**: `nextflow.config` sets `params`, `process` directives, `executor`, container engines, and named `profiles`. Selectors `withName:`\u002F`withLabel:` target specific processes. See `references\u002Fconfiguration.md`.\n- **meta map** (nf-core): the convention of carrying a metadata map (`[ id:'sample1', single_end:false ]`) alongside files in input\u002Foutput tuples so samples stay labeled through the pipeline. See `references\u002Fdeveloping.md`.\n\n## nf-core tools CLI\n\nnf-core tools (v3+) group subcommands under `pipelines`, `modules`, and `subworkflows`. (Bare forms like `nf-core lint` still work but warn — prefer the grouped form.)\n\n| Command | Purpose |\n|---------|---------|\n| `nf-core pipelines list` | List\u002Fsearch nf-core pipelines (`--json`, keywords) |\n| `nf-core pipelines create` | Scaffold a new pipeline from the nf-core template |\n| `nf-core pipelines launch \u003Cname>` | Interactive, schema-driven run command + params file |\n| `nf-core pipelines download \u003Cname>` | Download pipeline + containers for offline\u002FHPC use |\n| `nf-core pipelines lint` | Lint a pipeline against nf-core standards (run in repo root) |\n| `nf-core pipelines schema build` | Build\u002Fedit `nextflow_schema.json` via web GUI |\n| `nf-core pipelines create-params-file \u003Cname>` | Generate a documented YAML params file |\n| `nf-core pipelines bump-version` \u002F `sync` | Bump version \u002F sync with template updates |\n| `nf-core modules list\u002Finfo\u002Finstall\u002Fupdate\u002Fremove` | Manage modules from nf-core\u002Fmodules |\n| `nf-core modules create` \u002F `lint` \u002F `test` | Author, lint, and nf-test a module |\n| `nf-core modules patch` \u002F `bump-versions` | Patch an installed module \u002F bump tool versions |\n| `nf-core subworkflows install\u002Fcreate\u002Flint\u002Ftest` | Same lifecycle for subworkflows |\n\nFull command reference, flags, and examples: `references\u002Fnf-core-tools.md`.\n\n## Essential `nextflow` CLI\n\n| Command | Purpose |\n|---------|---------|\n| `nextflow run \u003Cpipeline> -profile \u003Cp> --outdir \u003Cdir>` | Run a pipeline (path, `.nf`, or `user\u002Frepo`) |\n| `-resume` | Reuse cached results from prior run |\n| `-r \u003Crev>` | Run a specific git revision\u002Ftag\u002Fbranch |\n| `-params-file params.yml` | Supply parameters from YAML\u002FJSON |\n| `-c custom.config` | Layer in an extra config file |\n| `-with-report -with-trace -with-timeline -with-dag flow.html` | Execution report, trace, timeline, DAG |\n| `-stub-run` | Run `stub:` blocks only (dry-run plumbing) |\n| `nextflow log` | Inspect past runs |\n| `nextflow clean -f -before \u003Crun>` | Delete old `work\u002F` data |\n| `nextflow pull \u002F drop \u002F list \u002F info \u003Crepo>` | Manage cached remote pipelines |\n\nConfig, executors, caching internals, and tracing details: `references\u002Fconfiguration.md`.\n\n## Best Practices (high-value habits)\n\n- **Always `test` first**: `-profile test,docker` (or `singularity`\u002F`conda`) before real data — fast and catches environment problems.\n- **Pin everything**: pipeline revision (`-r`), `NXF_VER`, and tool versions (containers). Don't run `latest` for science you'll publish.\n- **Use `-resume`** and understand caching: a task re-runs if its inputs, script, or container change. See cache-debugging in `references\u002Fconfiguration.md`.\n- **Parameterize via config\u002Fparams-file**, not hardcoded paths. Keep `params` and profiles in `nextflow.config`.\n- **One container\u002Fconda env per process**; never rely on tools installed on the host.\n- **For nf-core dev**: reuse existing modules (`nf-core modules install`) before writing new ones; pass tool flags through `ext.args` (not hardcoded in the script); always include a `stub:` block and nf-test tests; run `nf-core pipelines lint` and `prettier` before committing.\n- **Right-size resources** with `process_low\u002Fmedium\u002Fhigh` labels and `errorStrategy 'retry'` with dynamic `task.attempt` scaling instead of one giant request.\n- **Write forward-compatible syntax**: the strict-syntax parser becomes the default in Nextflow 26.04. Prefer lowercase `channel.of(...)`, explicit closure params (`{ v -> ... }`), `def` for all variables, and `emit:`-named outputs. Check with `nextflow lint`.\n\n## Reference Files\n\nRead the relevant file when you need depth — each is self-contained:\n\n- `references\u002Flanguage.md` — DSL2 language: processes, directives, channels, operators, workflows (`take`\u002F`emit`), modules, dynamic resources, error handling.\n- `references\u002Fconfiguration.md` — `nextflow.config`, scopes, `profiles`, `withName`\u002F`withLabel` selectors, executors (local\u002FSLURM\u002Fcloud), caching\u002F`-resume` internals, tracing\u002Freports, the `nextflow` CLI.\n- `references\u002Fcontainers.md` — Docker, Singularity\u002FApptainer, Podman, Conda, Wave containers; choosing and enabling engines; common gotchas.\n- `references\u002Frunning-pipelines.md` — finding\u002Frunning nf-core pipelines, samplesheets, params files, reference genomes (iGenomes), offline runs, institutional configs, Seqera Platform.\n- `references\u002Fnf-core-tools.md` — complete `nf-core` CLI reference (pipelines\u002Fmodules\u002Fsubworkflows), flags, and workflows.\n- `references\u002Fdeveloping.md` — authoring nf-core pipelines & modules: template layout, module `main.nf`\u002F`meta.yml`, meta maps, `ext.args`\u002F`modules.config`, subworkflows, resource labels, linting & Harshil alignment style.\n- `references\u002Ftesting.md` — nf-test for modules\u002Fsubworkflows\u002Fpipelines: test structure, assertions, snapshots, tags, running tests, CI.\n\nOfficial docs: Nextflow https:\u002F\u002Fwww.nextflow.io\u002Fdocs\u002Flatest\u002F · nf-core https:\u002F\u002Fnf-co.re\u002Fdocs\u002F · Training https:\u002F\u002Ftraining.nextflow.io\u002F\n\n## Agent operating procedure\n\n1. **Check the environment.** Confirm tool versions, the reference genome\u002Fannotation build and the input formats (FASTQ, BAM, VCF, h5ad).\n2. **Pin down the inputs.** Confirm formats, identifiers and parameters from the data or the user. Ask rather than guess any value that changes the result.\n3. **Run a small version first.** Run the pipeline on a small subset (one sample, one chromosome, a few thousand cells) first.\n4. **Execute the full task** using the instructions and references above.\n5. **Validate the result.** Check QC metrics, sample identities, genome build consistency and batch effects before interpreting results.\n6. **Report.** State what was run (versions, commands, parameters), what was checked, and what is still uncertain.\n\n| If this happens | Do this |\n|---|---|\n| Genome builds or identifiers do not match between inputs | Stop and harmonize (liftover, ID mapping) before continuing. |\n| A function, flag or endpoint in these instructions is missing in the installed version | Check the installed version's own documentation (`help()`, `--help`, official docs), adapt, and tell the user. Never invent an API. |\n| A required input, identifier or parameter is ambiguous | Ask the user, or state the assumption explicitly before running. |\n\n**Integrity rules**\n\n- Never fabricate results, parameters, identifiers, citations or statistics. If something cannot be run or verified, say so plainly.\n- Do not interpret biological significance beyond what the statistics support; report multiple-testing correction.\n- Treat version-specific details here as possibly outdated: confirm them against the official documentation for the installed version.\n- Ask before actions that cost money, consume shared GPUs or cloud quota, touch personal or patient data, or cannot be undone.\n\n## Related skills\n\n- `pacsomatic`: Operator toolkit for nf-core\u002Fpacsomatic matched tumor-normal workflows from BAM inputs.\n- `bulk-rnaseq`: End-to-end bulk RNA-seq orchestrator — takes raw FASTQ reads through QC and trimming (FastQC, fastp\u002FTrim Galore), alignment and quantificat…\n- `latchbio-integration`: Build, register, debug, and operate bioinformatics workflows on Latch using the Python SDK, CLI, Latch Data and Registry, Nextflow, Snakema…\n","# Nextflow\n\n## Overview\n\nNextflow 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.\n\nKey ideas:\n- **Dataflow programming**: pipelines are `process` tasks connected by **channels**. Nextflow infers execution order and parallelism from data dependencies — there is no explicit scheduler to write.\n- **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\u002Fprofiles, not code.\n- **Reproducibility**: per-task containers (Docker\u002FSingularity\u002FApptainer\u002FConda\u002FWave) + `-resume` caching + pinned pipeline revisions.\n- **DSL2** is the modern, required syntax: modular `process`\u002F`workflow`\u002F`include` definitions.\n\nThis skill covers both **running** existing pipelines and **developing** your own (Nextflow language + nf-core conventions, testing with nf-test, configuration, and deployment).\n\n## When to Use This Skill\n\nUse this skill when the user wants to:\n- Run an nf-core or custom Nextflow pipeline, or debug a failing\u002Fresuming run.\n- Write or modify `.nf` scripts, `nextflow.config`, profiles, or `nextflow_schema.json`.\n- Author or test nf-core-style modules\u002Fsubworkflows (`main.nf`, `meta.yml`, `tests\u002F`, nf-test).\n- Configure executors, containers, or resources; scale to HPC or cloud.\n- Build a reproducible scientific\u002Fbioinformatics workflow (even if \"Nextflow\" is not named).\n- Understand processes, channels, operators, `take`\u002F`emit`, `publishDir`, `ext.args`, meta maps.\n\n## Setup\n\nNextflow needs **Bash** and **Java 17 or newer** (17–25 supported). Verify with `java -version`.\n\n```bash\n# Install Nextflow (self-contained launcher)\ncurl -s https:\u002F\u002Fget.nextflow.io | bash      # creates .\u002Fnextflow\nsudo mv nextflow \u002Fusr\u002Flocal\u002Fbin\u002F             # put on PATH\nnextflow info                                # verify\n\n# Or via conda\u002Fbioconda (also gets a managed Java)\nconda create -n nf -c bioconda -c conda-forge nextflow nf-core\n```\n\n```bash\n# nf-core tools (Python) for creating\u002Flinting\u002Frunning nf-core assets\nuv pip install nf-core            # or: conda install -c bioconda nf-core\nnf-core --version\n```\n\nPin the engine for reproducibility: `export NXF_VER=24.10.0` (use an [edge] release only if needed). For air-gapped\u002FHPC, see `references\u002Frunning-pipelines.md` (offline mode) and `references\u002Fconfiguration.md`.\n\n## Two Modes of Work\n\nDecide which path the user is on — it changes everything:\n\n| Goal | Start here |\n|------|-----------|\n| **Run** an existing pipeline (nf-core or a `.nf` you were given) | `references\u002Frunning-pipelines.md` |\n| **Develop** a new pipeline \u002F module \u002F subworkflow | `references\u002Flanguage.md` + `references\u002Fdeveloping.md` |\n| **Configure \u002F scale** (HPC, cloud, containers, resources) | `references\u002Fconfiguration.md` + `references\u002Fcontainers.md` |\n| **Test** modules\u002Fpipelines | `references\u002Ftesting.md` |\n\n## Quick Start\n\n### Run an nf-core pipeline\n\nAlways smoke-test with the bundled `test` profile first; it uses tiny data and proves your environment works.\n\n```bash\n# 1. Confirm setup works (downloads pipeline + tiny test data)\nnextflow run nf-core\u002Frnaseq -profile test,docker --outdir results\n\n# 2. Real run: pin a revision (-r), pick a container engine, pass inputs\nnextflow run nf-core\u002Frnaseq -r 3.14.0 \\\n  -profile docker \\\n  --input samplesheet.csv \\\n  --genome GRCh38 \\\n  --outdir results \\\n  -resume\n```\n\n- `-profile` (single dash) selects bundled config profiles; **combine** them comma-separated, e.g. `test,docker`. Container\u002Finfra profiles (`docker`, `singularity`, `conda`) are mutually exclusive — pick one.\n- `--input`, `--genome`, `--outdir` (double dash) are **pipeline** parameters. nf-core pipelines take a **samplesheet CSV**, not loose files.\n- `-resume` reuses cached results from the last run. `-r \u003Cversion>` pins a release for reproducibility.\n\nUse `nf-core pipelines launch \u003Cname>` for an interactive, schema-validated way to build the command and a `-params-file`. See `references\u002Frunning-pipelines.md`.\n\n### Write a minimal pipeline\n\n```nextflow\n#!\u002Fusr\u002Fbin\u002Fenv nextflow\n\nprocess SAYHELLO {\n    tag \"$greeting\"\n    publishDir \"results\", mode: 'copy'\n\n    input:\n    val greeting\n\n    output:\n    path \"${greeting}.txt\"\n\n    script:\n    \"\"\"\n    echo '$greeting world' > ${greeting}.txt\n    \"\"\"\n}\n\nworkflow {\n    channel.of('hello', 'bonjour', 'hola') | SAYHELLO\n}\n```\n\n```bash\nnextflow run main.nf            # add -resume on reruns\n```\n\nThe full language (processes, channels, operators, DSL2 workflows with `take`\u002F`main`\u002F`emit`, modules) is in `references\u002Flanguage.md`.\n\n## Core Concepts at a Glance\n\n- **Process**: a unit of work that runs a script (Bash by default). Declares `input:`, `output:`, optional `directives` (resources, container, `publishDir`, `tag`, `errorStrategy`), and a `script:`\u002F`shell:`\u002F`exec:` block. Each task runs in its own isolated work directory (`work\u002Fxx\u002Fyy…`).\n- **Channel**: the async queues that connect processes. **Queue channels** are consumable streams; **value channels** hold a single reusable value. Created with factories like `channel.of`, `channel.fromPath`, `channel.fromFilePairs`, `channel.value`.\n- **Operator**: transforms\u002Fcombines channels — `map`, `filter`, `collect`, `groupTuple`, `join`, `combine`, `mix`, `flatten`, `branch`, `multiMap`, `splitCsv`, `view`, `set`.\n- **Workflow**: composes processes. DSL2 workflows can declare `take:` (inputs), `main:` (logic), `emit:` (named outputs) and be `include`d as subworkflows. The unnamed `workflow {}` is the entry point.\n- **Module**: a `.nf` file exposing processes\u002Fworkflows via `include { NAME } from '.\u002Fpath'` (supports `as` aliasing).\n- **Configuration**: `nextflow.config` sets `params`, `process` directives, `executor`, container engines, and named `profiles`. Selectors `withName:`\u002F`withLabel:` target specific processes. See `references\u002Fconfiguration.md`.\n- **meta map** (nf-core): the convention of carrying a metadata map (`[ id:'sample1', single_end:false ]`) alongside files in input\u002Foutput tuples so samples stay labeled through the pipeline. See `references\u002Fdeveloping.md`.\n\n## nf-core tools CLI\n\nnf-core tools (v3+) group subcommands under `pipelines`, `modules`, and `subworkflows`. (Bare forms like `nf-core lint` still work but warn — prefer the grouped form.)\n\n| Command | Purpose |\n|---------|---------|\n| `nf-core pipelines list` | List\u002Fsearch nf-core pipelines (`--json`, keywords) |\n| `nf-core pipelines create` | Scaffold a new pipeline from the nf-core template |\n| `nf-core pipelines launch \u003Cname>` | Interactive, schema-driven run command + params file |\n| `nf-core pipelines download \u003Cname>` | Download pipeline + containers for offline\u002FHPC use |\n| `nf-core pipelines lint` | Lint a pipeline against nf-core standards (run in repo root) |\n| `nf-core pipelines schema build` | Build\u002Fedit `nextflow_schema.json` via web GUI |\n| `nf-core pipelines create-params-file \u003Cname>` | Generate a documented YAML params file |\n| `nf-core pipelines bump-version` \u002F `sync` | Bump version \u002F sync with template updates |\n| `nf-core modules list\u002Finfo\u002Finstall\u002Fupdate\u002Fremove` | Manage modules from nf-core\u002Fmodules |\n| `nf-core modules create` \u002F `lint` \u002F `test` | Author, lint, and nf-test a module |\n| `nf-core modules patch` \u002F `bump-versions` | Patch an installed module \u002F bump tool versions |\n| `nf-core subworkflows install\u002Fcreate\u002Flint\u002Ftest` | Same lifecycle for subworkflows |\n\nFull command reference, flags, and examples: `references\u002Fnf-core-tools.md`.\n\n## Essential `nextflow` CLI\n\n| Command | Purpose |\n|---------|---------|\n| `nextflow run \u003Cpipeline> -profile \u003Cp> --outdir \u003Cdir>` | Run a pipeline (path, `.nf`, or `user\u002Frepo`) |\n| `-resume` | Reuse cached results from prior run |\n| `-r \u003Crev>` | Run a specific git revision\u002Ftag\u002Fbranch |\n| `-params-file params.yml` | Supply parameters from YAML\u002FJSON |\n| `-c custom.config` | Layer in an extra config file |\n| `-with-report -with-trace -with-timeline -with-dag flow.html` | Execution report, trace, timeline, DAG |\n| `-stub-run` | Run `stub:` blocks only (dry-run plumbing) |\n| `nextflow log` | Inspect past runs |\n| `nextflow clean -f -before \u003Crun>` | Delete old `work\u002F` data |\n| `nextflow pull \u002F drop \u002F list \u002F info \u003Crepo>` | Manage cached remote pipelines |\n\nConfig, executors, caching internals, and tracing details: `references\u002Fconfiguration.md`.\n\n## Best Practices (high-value habits)\n\n- **Always `test` first**: `-profile test,docker` (or `singularity`\u002F`conda`) before real data — fast and catches environment problems.\n- **Pin everything**: pipeline revision (`-r`), `NXF_VER`, and tool versions (containers). Don't run `latest` for science you'll publish.\n- **Use `-resume`** and understand caching: a task re-runs if its inputs, script, or container change. See cache-debugging in `references\u002Fconfiguration.md`.\n- **Parameterize via config\u002Fparams-file**, not hardcoded paths. Keep `params` and profiles in `nextflow.config`.\n- **One container\u002Fconda env per process**; never rely on tools installed on the host.\n- **For nf-core dev**: reuse existing modules (`nf-core modules install`) before writing new ones; pass tool flags through `ext.args` (not hardcoded in the script); always include a `stub:` block and nf-test tests; run `nf-core pipelines lint` and `prettier` before committing.\n- **Right-size resources** with `process_low\u002Fmedium\u002Fhigh` labels and `errorStrategy 'retry'` with dynamic `task.attempt` scaling instead of one giant request.\n- **Write forward-compatible syntax**: the strict-syntax parser becomes the default in Nextflow 26.04. Prefer lowercase `channel.of(...)`, explicit closure params (`{ v -> ... }`), `def` for all variables, and `emit:`-named outputs. Check with `nextflow lint`.\n\n## Reference Files\n\nRead the relevant file when you need depth — each is self-contained:\n\n- `references\u002Flanguage.md` — DSL2 language: processes, directives, channels, operators, workflows (`take`\u002F`emit`), modules, dynamic resources, error handling.\n- `references\u002Fconfiguration.md` — `nextflow.config`, scopes, `profiles`, `withName`\u002F`withLabel` selectors, executors (local\u002FSLURM\u002Fcloud), caching\u002F`-resume` internals, tracing\u002Freports, the `nextflow` CLI.\n- `references\u002Fcontainers.md` — Docker, Singularity\u002FApptainer, Podman, Conda, Wave containers; choosing and enabling engines; common gotchas.\n- `references\u002Frunning-pipelines.md` — finding\u002Frunning nf-core pipelines, samplesheets, params files, reference genomes (iGenomes), offline runs, institutional configs, Seqera Platform.\n- `references\u002Fnf-core-tools.md` — complete `nf-core` CLI reference (pipelines\u002Fmodules\u002Fsubworkflows), flags, and workflows.\n- `references\u002Fdeveloping.md` — authoring nf-core pipelines & modules: template layout, module `main.nf`\u002F`meta.yml`, meta maps, `ext.args`\u002F`modules.config`, subworkflows, resource labels, linting & Harshil alignment style.\n- `references\u002Ftesting.md` — nf-test for modules\u002Fsubworkflows\u002Fpipelines: test structure, assertions, snapshots, tags, running tests, CI.\n\nOfficial docs: Nextflow https:\u002F\u002Fwww.nextflow.io\u002Fdocs\u002Flatest\u002F · nf-core https:\u002F\u002Fnf-co.re\u002Fdocs\u002F · Training https:\u002F\u002Ftraining.nextflow.io\u002F\n\n## Agent operating procedure\n\n1. **Check the environment.** Confirm tool versions, the reference genome\u002Fannotation build and the input formats (FASTQ, BAM, VCF, h5ad).\n2. **Pin down the inputs.** Confirm formats, identifiers and parameters from the data or the user. Ask rather than guess any value that changes the result.\n3. **Run a small version first.** Run the pipeline on a small subset (one sample, one chromosome, a few thousand cells) first.\n4. **Execute the full task** using the instructions and references above.\n5. **Validate the result.** Check QC metrics, sample identities, genome build consistency and batch effects before interpreting results.\n6. **Report.** State what was run (versions, commands, parameters), what was checked, and what is still uncertain.\n\n| If this happens | Do this |\n|---|---|\n| Genome builds or identifiers do not match between inputs | Stop and harmonize (liftover, ID mapping) before continuing. |\n| A function, flag or endpoint in these instructions is missing in the installed version | Check the installed version's own documentation (`help()`, `--help`, official docs), adapt, and tell the user. Never invent an API. |\n| A required input, identifier or parameter is ambiguous | Ask the user, or state the assumption explicitly before running. |\n\n**Integrity rules**\n\n- Never fabricate results, parameters, identifiers, citations or statistics. If something cannot be run or verified, say so plainly.\n- Do not interpret biological significance beyond what the statistics support; report multiple-testing correction.\n- Treat version-specific details here as possibly outdated: confirm them against the official documentation for the installed version.\n- Ask before actions that cost money, consume shared GPUs or cloud quota, touch personal or patient data, or cannot be undone.\n\n## Related skills\n\n- `pacsomatic`: Operator toolkit for nf-core\u002Fpacsomatic matched tumor-normal workflows from BAM inputs.\n- `bulk-rnaseq`: End-to-end bulk RNA-seq orchestrator — takes raw FASTQ reads through QC and trimming (FastQC, fastp\u002FTrim Galore), alignment and quantificat…\n- `latchbio-integration`: Build, register, debug, and operate bioinformatics workflows on Latch using the Python SDK, CLI, Latch Data and Registry, Nextflow, Snakema…\n",{"name":5,"license":15,"metadata":24,"description":7},{"tags":25,"version":26,"category":27,"maintainer":28},"Nextflow, nf-core, bioinformatics pipelines, workflow management, genomics","1.2","life-sciences","Kalaris Labs","main","29fe36d26127205057d5e0ed8425f6b0e9a8c13a","skills\u002Fnextflow",16,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills","https:\u002F\u002Fdocs.kalarislabs.com\u002Fresearch-agent-skills","https:\u002F\u002Fgithub.com\u002FKalarisLabs","kalarislabs.com","Applied AI lab building the infrastructure for the agentic era","2026-11-14 17:49:08",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add KalarisLabs\u002Fresearch-agent-skills --skill nextflow",{"tool":45,"command":46},"bunx","bunx skills add KalarisLabs\u002Fresearch-agent-skills --skill nextflow",{"tool":48,"command":49},"pnpm","pnpm dlx skills add KalarisLabs\u002Fresearch-agent-skills --skill nextflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002FSKILL.md",true,[53,59,63,67,71,75,79],{"path":54,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":57,"sourceHtmlUrl":58},"references\u002Fconfiguration.md","REFERENCE","参考文档",11318,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002Freferences\u002Fconfiguration.md",{"path":60,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":61,"sourceHtmlUrl":62},"references\u002Fcontainers.md",4598,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002Freferences\u002Fcontainers.md",{"path":64,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":65,"sourceHtmlUrl":66},"references\u002Fdeveloping.md",15378,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002Freferences\u002Fdeveloping.md",{"path":68,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Flanguage.md",15318,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002Freferences\u002Flanguage.md",{"path":72,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fnf-core-tools.md",6357,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002Freferences\u002Fnf-core-tools.md",{"path":76,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Frunning-pipelines.md",6806,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002Freferences\u002Frunning-pipelines.md",{"path":80,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Ftesting.md",6744,"https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fnextflow\u002Freferences\u002Ftesting.md",[84,92,99,106,113,120],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M74Z8MGT305R11SNY5G28QH5","plos","Prepare manuscripts for PLOS journals (PLOS ONE, PLOS Biology, PLOS Computational Biology, PLOS Genetics, PLOS Medicine, PLOS Pathogens, PLOS Neglected Tropical Diseases, PLOS Global Public Health and others), covering structure, abstract and author summary, Vancouver-style references, the mandatory data availability policy, ethics and financial disclosure statements, figure requirements (PACE), the PLOS LaTeX template, reporting guidelines and PLOS ONE's publication criteria. Use when targeting any PLOS journal or checking compliance with PLOS policies.","MIT","https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fplos\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":19},"01M74Z8CCN9APXYHNQ95V1EBGT","pkpd-modeling","Pharmacokinetic and pharmacodynamic modelling and simulation - non-compartmental analysis, compartmental and population PK, PK\u002FPD and exposure-response, TMDD, PBPK orientation, bioequivalence, allometric scaling and first-in-human dose, drug interaction prediction, and Bayesian therapeutic drug monitoring. Use when analysing concentration-time data, deriving exposure metrics, fitting PK or PD models, or evaluating dosing regimens. Triggers include \"pharmacokinetics\", \"pharmacodynamics\", \"PK\u002FPD\", \"NCA\", \"non-compartmental\", \"AUC\", \"Cmax\", \"lambda z\", \"half-life\", \"clearance\", \"volume of distribution\", \"compartmental model\", \"population PK\", \"popPK\", \"NONMEM\", \"nlmixr2\", \"Pharmpy\", \"Monolix\", \"exposure-response\", \"Emax\", \"EC50\", \"indirect response\", \"effect compartment\", \"TMDD\", \"PBPK\", \"bioequivalence\", \"RSABE\", \"ABEL\", \"allometric scaling\", \"first-in-human\", \"MABEL\", \"drug-drug interaction\", \"DDI\", \"ICH M12\", \"concentration-QTc\", \"therapeutic drug monitoring\", \"MIPD\", and \"dosing regimen\".","https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fpkpd-modeling\u002FSKILL.md",[],[],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":19},"01M74Z86YHJJ1FM3X87BHN76KZ","pinecone","Guides use of Pinecone, a managed serverless vector database, through its Python client and the LangChain and LlamaIndex integrations. Covers creating indexes, upserting and querying vectors, metadata filtering, namespaces, hybrid dense and sparse search, index management, and deleting vectors. Use when building a production RAG system on a hosted vector store, adding semantic search or recommendations without running infrastructure, isolating per-user or per-tenant data with namespaces, combining dense and sparse vectors in one query, or filtering results by metadata. Do not use for self-hosted or local stores (Chroma, Weaviate) or offline similarity search (FAISS).","https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fpinecone\u002FSKILL.md",[],[],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":19},"01M74Z80T6E89SAJ8MYDD0767Q","pi-agent","Build with and use Pi, the minimal terminal coding harness. Use for installing Pi, configuring providers\u002Fmodels\u002Fsettings\u002Fenvironment variables, creating Pi skills\u002Fextensions\u002Fpackages\u002Fthemes\u002Fprompt templates, embedding Pi through the SDK, integrating over RPC or JSON event streams, parsing sessions, running local models through the llama.cpp router, developing custom Pi providers and TUI components, or using ecosystem packages such as pi-subagents (delegation\u002Forchestration), pi-mcp-adapter (MCP servers), pi-interview (interactive forms), and pi-web-access (web search, fetching, video understanding).","https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fpi-agent\u002FSKILL.md",[],[],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":19},"01M74Z7WF1Y8Q3VFAQPPPRAFMV","phoenix-observability","Open-source AI observability platform for LLM tracing, evaluation, and monitoring. Use when debugging LLM applications with detailed traces, running evaluations on datasets, or monitoring production AI systems with real-time insights.","https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fphoenix-observability\u002FSKILL.md",[],[],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":88,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":19},"01M74Z7HNEH1A2AVYR3G1X2QV6","peft-fine-tuning","Fine-tunes LLMs with Hugging Face PEFT, using LoRA, QLoRA, IA3, AdaLoRA, prefix tuning, and prompt tuning so that under 1% of parameters are trained. Covers rank, alpha, and target module selection, loading and merging adapters, multi-adapter serving, and integration with TRL SFTTrainer, Axolotl, and vLLM. Use when fine-tuning 7B-70B models on limited GPU memory, when running QLoRA on a single 24GB GPU, when choosing LoRA rank and alpha, when merging or swapping adapters on one base model, or when debugging CUDA OOM or an adapter that does not apply. Not for full fine-tuning of small models under 1B parameters or cases needing all weights updated.","https:\u002F\u002Fgithub.com\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fpeft-fine-tuning\u002FSKILL.md",[],[]]