Address editorial comments from PR review

- Add link to Hello Nextflow configuration section in 01_run_demo.md
- Rewrite workflow summary in 02_rewrite_hello.md to be more natural
- Remove redundant sentence about nf-core tooling in 04_make_module.md
- Restructure ext.args section with high-level overview first
- Improve ext.args explanation to be more specific about what it is
- Separate ext.args and publishDir discussions for better flow

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

Author: pinin4fjords

docs/hello_nf-core/01_run_demo.md

@@ -204,6 +204,8 @@ We're also going to specify `-profile docker,test`, which by nf-core convention
     nf-core pipelines are designed to work with containers (Docker, Singularity, etc.) to ensure reproducibility and eliminate software installation issues.
     The profile system allows you to easily switch between different container engines or execution environments.
 
+    For more details on how configuration profiles work in Nextflow, see [Hello Nextflow Part 6: Configuration](../hello_nextflow/06_hello_configuration.md).
+
 Let's try it!
 
 ```bash

docs/hello_nf-core/02_rewrite_hello.md

@@ -292,7 +292,8 @@ If you haven't completed the [Hello Nextflow](../hello_nextflow/index.md) traini
 4. **Collects all uppercase greetings** into a single batch file
 5. **Adds ASCII art** using cowpy to display the collected greetings with a fun character
 
-The workflow uses four Nextflow processes (`sayHello`, `convertToUpper`, `collectGreetings`, and `cowpy`) organized into separate module files, takes an input CSV file of greetings, and produces a whimsical ASCII art output file.
+The workflow takes a CSV file containing greetings, runs four consecutive steps to transform the greetings, and writes them out as part of an ASCII picture.
+These four steps are implemented as modularized Nextflow processes (`sayHello`, `convertToUpper`, `collectGreetings`, and `cowpy`) organized into separate module files.
 
 We provide you with a clean, fully functional copy of the completed Hello Nextflow workflow in the directory `original-hello` along with its modules and the default CSV file it expects to use as input.
 

docs/hello_nf-core/04_make_module.md

@@ -12,8 +12,6 @@ We'll apply three essential nf-core patterns incrementally:
 2. **`ext.args`**: Keep the module interface minimal by handling optional tool arguments via configuration rather than as inputs
 3. **`ext.prefix`**: Standardize output file naming with configurable prefixes
 
-Once you understand these patterns, we'll show you how to use the official nf-core tooling to create modules efficiently.
-
 !!! note
 
     This section assumes you have completed [Part 3: Use an nf-core module](./03_use_module.md) and have integrated the `CAT_CAT` module into your pipeline.
@@ -160,24 +158,30 @@ executor >  local (8)
 -[core/hello] Pipeline completed successfully-
 ```
 
-### 1.2. Simplify the interface with ext.args
+### 1.2. Control module behavior via configuration
 
-Now let's address another nf-core pattern: simplifying module interfaces by using `ext.args` for optional command-line arguments.
+Currently, our `cowpy` module hardcodes two aspects of its behavior:
 
-Currently, our `cowpy` module requires the `character` parameter to be passed as an input via the process `input:` block.
-This works, but it forces us to provide a value for `character` every time we call the process, even if we're happy with a default.
-For tools with many optional parameters, having to provide values for all of them gets annoying fast.
+1. **Tool arguments**: The `character` parameter is passed as a process input, so we must provide a value every time we call the process
+2. **Output publishing**: The module contains a `publishDir` directive, making publishing decisions at the module level
 
-nf-core modules use a different approach for **tool configuration arguments**: instead of declaring inputs for every tool option, they use `ext.args` to pass these via configuration.
-This keeps the module interface focused on essential data (files, metadata, and any mandatory per-sample parameters), while tool configuration options are handled through `ext.args`.
+This makes the module less flexible.
+For tool arguments, we're forced to provide values even when we'd be happy with defaults, which gets cumbersome for tools with many optional parameters.
+For output publishing, we can't control where outputs go at the workflow level - each module makes its own publishing decisions.
 
-#### 1.2.1. Understanding ext.args
+nf-core modules handle both of these differently, controlling tool arguments and output publishing through configuration files.
+This centralizes control at the workflow level and makes modules more reusable.
 
-The `task.ext.args` pattern is an nf-core convention for passing command-line arguments to tools through configuration rather than as process inputs.
+Let's update our module to follow both of these nf-core configuration patterns.
 
-!!! note "ext.args can do more"
+#### 1.2.1. Tool arguments with ext.args
 
-    The `ext.args` system has powerful additional capabilities not covered here, including switching argument values dynamically based on metadata. See the [nf-core module specifications](https://nf-co.re/docs/guidelines/components/modules) for more details.
+For tool arguments, nf-core modules use a special configuration variable called `task.ext.args`.
+Instead of declaring process inputs for every tool option, you write the module to reference `task.ext.args` in its command line.
+This variable can be set in configuration files to pass arguments to the tool.
+When you configure a module to use `task.ext.args`, it checks if the variable is defined and includes those arguments in the tool's command line.
+
+This approach keeps the module interface focused on essential data (files, metadata, and any mandatory per-sample parameters), while tool configuration options are handled separately through configuration.
 
 Benefits of this approach:
 
@@ -187,9 +191,13 @@ Benefits of this approach:
 - **Portability**: Modules can be reused without hardcoded tool options
 - **No workflow changes**: Adding or changing tool options doesn't require updating workflow code
 
+!!! note "ext.args can do more"
+
+    The `ext.args` system has powerful additional capabilities not covered here, including switching argument values dynamically based on metadata. See the [nf-core module specifications](https://nf-co.re/docs/guidelines/components/modules) for more details.
+
 #### 1.2.2. Centralized publishing configuration
 
-Before we update the module to use `ext.args`, let's address an important nf-core convention: **modules should not contain hardcoded `publishDir` directives**.
+For output publishing, nf-core pipelines centralize control at the workflow level by configuring `publishDir` in `conf/modules.config` rather than in individual modules.
 
 Currently, our `cowpy` module has `publishDir 'results', mode: 'copy'` which hardcodes the output location.
 In nf-core pipelines, publishing is instead configured in `conf/modules.config`.