Address Geraldine's editorial comments on Hello nf-core

This commit addresses the straightforward editorial feedback from
Geraldine's review of PR #691, focusing on improving clarity and
messaging for the research pipeline audience.

Changes:
- Strip em-dashes throughout (replace with periods/separate sentences)
- Revise messaging to avoid implying production vs research dichotomy
- Remove "production-ready" claims about the toy example
- Improve explanations of workflow summaries and technical concepts
- Clarify ext.args benefits (avoiding many optional input parameters)
- Replace jargon (e.g., "test harness") with simpler terms
- Make "learn by doing" messaging more specific and actionable

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

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

Author: pinin4fjords

docs/hello_nf-core/00_orientation.md

@@ -36,13 +36,13 @@ Now let's have a look at the contents of this directory.
 ## What you'll learn
 
 This training course teaches you the core concepts for building nf-core-style pipelines.
-We can't cover everything—nf-core pipelines have many features and conventions developed by the community over years—but we focus on the essential concepts that will help you get started and understand how nf-core works.
+We can't cover everything. nf-core pipelines have many features and conventions developed by the community over years. However, we focus on the essential concepts that will help you get started and understand how nf-core works.
 
-First, you'll **run an existing nf-core pipeline** to understand how they're structured and what makes them different from basic Nextflow workflows.
+First, you'll **run an existing nf-core pipeline** to see what makes them different from basic Nextflow workflows.
 The extensive directory structure, configuration system, and standardized conventions might seem overwhelming at first, but understanding them is essential for working within the template.
 
 Next, you'll **adapt a simple workflow to the nf-core template scaffold**.
-Most real pipelines start from existing code, so learning how to restructure workflows to work within nf-core's nested workflow system is a practical skill you'll use repeatedly.
+Many pipeline development efforts start from existing code, so learning how to restructure workflows to work within nf-core's nested workflow system is a practical skill you'll use repeatedly.
 
 Then you'll discover one of nf-core's biggest advantages: the **community modules library**.
 Instead of writing every process from scratch, you'll learn to integrate pre-built, tested modules that wrap common bioinformatics tools.
@@ -52,9 +52,9 @@ Of course, the modules library doesn't have everything, so you'll **create your
 You'll learn the specific structure, naming conventions, and metadata requirements that make modules shareable and maintainable by the community.
 
 Finally, you'll implement **comprehensive validation** for both command-line parameters and input data files using nf-schema.
-This catches errors before pipelines run, providing fast feedback and clear error messages—a key differentiator between research scripts and production pipelines.
+This catches errors before pipelines run, providing fast feedback and clear error messages. This type of upfront validation makes pipelines more robust and easier to use.
 
-By the end, you'll have transformed a basic Nextflow workflow into a production-ready, nf-core-style pipeline with standardized structure, reusable components, and robust validation.
+By the end, you'll have transformed a basic Nextflow workflow into an nf-core-style pipeline with standardized structure, reusable components, and robust validation.
 
 ## Materials provided
 

docs/hello_nf-core/01_run_demo.md

@@ -190,7 +190,7 @@ params {
 The test profile shows us what has been pre-configured for testing: most notably, the `input` parameter is already set to point to a test dataset, so we don't need to provide our own data.
 
 The comment block at the top also includes a usage example showing how to run with this test profile.
-Notice that it includes `--outdir <OUTDIR>` - this tells us we'll need to specify an output directory when we run the pipeline.
+Notice that it includes `--outdir <OUTDIR>`. This tells us we'll need to specify an output directory when we run the pipeline.
 
 ### 2.2. Run the pipeline
 

docs/hello_nf-core/02_rewrite_hello.md

@@ -529,8 +529,8 @@ That is going to be defined in the parent workflow, also called the **entrypoint
 
 ### 2.6. Make a dummy entrypoint workflow
 
-Before integrating our composable workflow into the complex nf-core scaffold, let's verify it works correctly with a simple test harness.
-We can make a dummy entrypoint workflow to test the composable workflow in isolation.
+Before integrating our composable workflow into the complex nf-core scaffold, let's verify it works correctly.
+We can make a simple dummy entrypoint workflow to test the composable workflow in isolation.
 
 Create a blank file named `main.nf` in the same`original-hello` directory.
 

docs/hello_nf-core/04_make_module.md

@@ -1,15 +1,15 @@
 # Part 4: Make an nf-core module
 
-In this fourth part of the Hello nf-core training course, we show you how to create an nf-core module by learning the key conventions that make modules portable and maintainable.
+In this fourth part of the Hello nf-core training course, we show you how to create an nf-core module by applying the key conventions that make modules portable and maintainable.
 
 The nf-core project provides a command (`nf-core modules create`) that generates properly structured module templates automatically.
-However, for teaching purposes, we're going to **learn by doing**: transforming the local `cowpy` module in your `core-hello` pipeline into an nf-core-style module step-by-step.
-This hands-on approach will help you understand the patterns deeply, making you better equipped to work with nf-core modules in practice.
+However, for teaching purposes, we're going to start by doing it manually: transforming the local `cowpy` module in your `core-hello` pipeline into an nf-core-style module step-by-step.
+After that, we'll show you how to use the template-based module creation to work more efficiently in the future.
 
 We'll apply three essential nf-core patterns incrementally:
 
 1. **Metadata tuples**: Accept and propagate sample metadata through the workflow
-2. **`ext.args`**: Simplify the module interface by handling optional arguments via configuration
+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.
@@ -164,15 +164,20 @@ executor >  local (8)
 
 Now let's address another nf-core pattern: simplifying module interfaces by using `ext.args` for optional command-line arguments.
 
-Currently, our `cowpy` module requires the `character` parameter to be passed as a separate input. While this works, nf-core modules use a different approach for **tool configuration arguments**: instead of adding input parameters 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`.
+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.
+
+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`.
 
 #### 1.2.1. Understanding ext.args
 
-The `task.ext.args` pattern is an nf-core convention for passing command-line arguments to tools through configuration rather than as process inputs. Instead of adding input parameters for tool options, nf-core modules accept arguments through the `ext.args` configuration directive.
+The `task.ext.args` pattern is an nf-core convention for passing command-line arguments to tools through configuration rather than as process inputs.
 
-!!! note "ext.args can be dynamic"
+!!! note "ext.args can do more"
 
-    While `ext.args` is configured outside the module, it can access metadata to provide sample-specific values using closures. For example: `ext.args = { meta.single_end ? '--single' : '--paired' }`
+    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.
 
 Benefits of this approach: