Documentation

The keywords “MUST”, “MUST NOT”, “SHOULD”, etc. are to be interpreted as described in RFC 2119.

1 General

A config MUST have a Markdown-based documentation file describing how to use the config.

• docs/<config name>.md for an institutional config.
• docs/pipeline/<pipeline>/<config name>.md for an institutional pipeline-specific config.
• docs/pipeline/<pipeline>/<pipeline>.md for a global pipeline-specific config.

A pipeline-specific config MUST be linked within the institutional-level config documentation.

2 Scope of documentation

A config documentation Markdown file MUST contain information on how to use the config in the context of the infrastructure. For example, the documentation SHOULD describe how to load Nextflow and other requirements for execution, such as module load <...> or conda activate <...>.

The documentation MAY also provide additional recommendations, such as how to specify scratch or temporary directories using Nextflow-related environment variables.

The config documentation Markdown file MUST NOT contain generic information, such as installing Nextflow.

For offline or sensitive data infrastructures, the documentation MUST describe any special steps required (e.g., pre-pulling containers, local reference paths).

3 Description of environmental variables

Any mandatory parameter or environment variable required for pipeline execution MUST be described in the documentation. Non-mandatory but common parameters or environment variables SHOULD be described.

4 Examples in documentation

It is RECOMMENDED to include copy-pasteable command examples for launching an nf-core workflow with the test profile, for example using $USER rather than placeholders.