docs: Skill update

.claude/skills/docs-deslop/references/terminology.md → .claude/skills/docs-deslop/references/core/terminology.md

@@ -2,7 +2,7 @@
 
 The house terminology and formatting rules for Seqera Platform documentation — the product-specific calls that the general rules in `style-guide.md` and automated linters (such as Vale) don't make for you.
 
-This file is specific to Seqera Platform. Apply it whenever the docs are about Seqera Platform, the `tw` CLI, or the surrounding tools (Nextflow, Wave, Fusion, Studios, MultiQC). Don't invent UI text or product behavior — if you can't confirm a term, flag it rather than guess (see SKILL.md rule 8).
+This file is the core terminology for Seqera docs. Apply it whenever the docs are about Seqera Platform, the `tw` CLI, or the surrounding tools (Nextflow, Wave, Fusion, Studios, MultiQC). Each product also has an **exclusive** reference file under `../products/` with rules specific to that product — apply the detected product's file (step 2 of SKILL.md) *in addition to* this one. Don't invent UI text or product behavior — if you can't confirm a term, flag it rather than guess (see SKILL.md rule 8).
 
 ## Product and tool names
 

.claude/skills/docs-deslop/references/topic-types.md → .claude/skills/docs-deslop/references/core/topic-types.md

@@ -57,7 +57,7 @@ Rules:
 
 - **Title is `active verb + noun`**: `Launch a pipeline`, `Configure the compute environment`, `Delete a workspace`. Not `Pipeline launch` (that would be a concept).
 - **Lead with context**: "Do this task when you want to..." — one sentence on why the reader would do this.
-- **Prerequisites** (if any) as a bulleted list. Don't write `Ensure that...` or `You must have...` — the list is the assertion. **For Seqera Platform docs, follow the `docs-structure` skill's prerequisites convention** (`references/prerequisites.md`): wrap them in a `:::info[**Prerequisites**]` admonition with a `You need the following:` lead-in and noun-phrase bullets, not a plain `Prerequisites:` heading. For non-Seqera docs, use the heading `Prerequisites:` (always plural).
+- **Prerequisites** (if any) as a bulleted list. Don't write `Ensure that...` or `You must have...` — the list is the assertion. **For Seqera Platform docs, follow the `docs-structure` skill's prerequisites convention** (`references/core/prerequisites.md`): wrap them in a `:::info[**Prerequisites**]` admonition with a `You need the following:` lead-in and noun-phrase bullets, not a plain `Prerequisites:` heading. For non-Seqera docs, use the heading `Prerequisites:` (always plural).
 - **Steps** as a numbered list. Each step is one action. Use the pattern **location, then action**: "In the top bar, select **Search or go to** and find your project."
 - **One step → unordered list item**, not a numbered list of one.
 - **Imperative verbs**: "Select", "Create", "Run". Not "You should select", "You can run".
@@ -100,7 +100,7 @@ Troubleshooting documents named failure modes and their fixes.
 
 Rules:
 
-- **Move troubleshooting topics to the troubleshooting pages.** Troubleshooting content does not stay inline on concept, task, or reference pages — move it to the product's dedicated troubleshooting pages (for example, `platform-cloud/docs/troubleshooting_and_faqs/`), no matter how few entries, and leave a one-line pointer on the source page. Add to the feature's existing `<feature>_troubleshooting.md` page when one exists; create it (and a sidebar entry) when none fits. The `docs-structure` skill's `references/troubleshooting.md` owns the destination map — hand off per step 5 of SKILL.md.
+- **Move troubleshooting topics to the troubleshooting pages** when the product has them. Troubleshooting content does not stay inline on concept, task, or reference pages — move it to the product's dedicated troubleshooting destination (for example, `platform-cloud/docs/troubleshooting_and_faqs/`), no matter how few entries, and leave a one-line pointer on the source page. The `docs-structure` skill owns placement: its `references/core/troubleshooting.md` covers identifying and formatting an entry, and the detected product's `references/products/<product>.md` gives the destination and the existing-vs-new-page rule. Some products (MultiQC, Nextflow) have no destination — leave troubleshooting inline for those. Hand off per step 6 of SKILL.md.
 - **Three valid sub-types:**
   - **Introductory** topic (a sentence introducing the section: "When working with X, you might encounter the following issues.")
   - **Troubleshooting task** — title is active verb + noun ("Verify the compute environment", "Check the run logs")
@@ -129,7 +129,7 @@ Rules:
 - **Title starts with `Tutorial:`** followed by an active verb: `Tutorial: Launch your first pipeline`, `Tutorial: Run nf-core/rnaseq on AWS Batch`.
 - **Open with the goal**: one paragraph explaining what the reader will build and the expected outcome.
 - **Optionally list the steps** at the top so the reader sees the shape. For short tutorials, omit.
-- **"Before you begin" section** for prerequisites — friendlier framing than the `Prerequisites:` of a task. **On Seqera Platform docs, use the `docs-structure` skill's prerequisites convention instead** (`references/prerequisites.md`: `:::info[**Prerequisites**]` admonition with a `You need the following:` lead-in and noun-phrase bullets), for consistency with the rest of the docs.
+- **"Before you begin" section** for prerequisites — friendlier framing than the `Prerequisites:` of a task. **On Seqera Platform docs, use the `docs-structure` skill's prerequisites convention instead** (`references/core/prerequisites.md`: `:::info[**Prerequisites**]` admonition with a `You need the following:` lead-in and noun-phrase bullets), for consistency with the rest of the docs.
 - **Sections are tasks**, each starting with `## Do the first task` style headings using active verbs.
 - **Voice is friendlier than other types.** Light future tense is OK ("Next, you'll add the pipeline to the Launchpad"). Encouraging phrases between sections are OK. Be more conversational — but no marketing puffery.
 - **Tutorials do not introduce new features.** They combine existing ones into a working example.

.claude/skills/docs-deslop/references/products/fusion.md

@@ -0,0 +1,25 @@
+# Fusion (exclusive rules)
+
+Exclusive terminology and formatting rules for **Fusion** docs (`fusion_docs/`).
+These layer *on top of* the core references, including `../core/terminology.md`.
+
+Core `../core/terminology.md` already covers the Fusion **name** (capitalized; the
+Fusion file system) and the general house rules. Don't duplicate those here —
+this file is for rules exclusive to Fusion.
+
+> **Scaffold.** Populate from the Fusion docs themselves — **do not invent**
+> feature names, config keys, or product behavior; flag anything you can't
+> confirm (SKILL.md rule 8). Wave is often used alongside Fusion — see `wave.md`.
+
+## Feature and entity names
+
+<!-- Lowercase common nouns for Fusion's own concepts (per the pattern in
+     ../core/terminology.md). Populate from Fusion docs: e.g. mount, cache, client. -->
+
+_None confirmed yet._
+
+## Config, env vars, and mount paths
+
+<!-- Fusion-specific config keys, environment variables, and mount paths, in backticks. -->
+
+_None confirmed yet._

.claude/skills/docs-deslop/references/products/multiqc.md

@@ -0,0 +1,27 @@
+# MultiQC (exclusive rules)
+
+Exclusive terminology and formatting rules for **MultiQC** docs (`multiqc_docs/`).
+These layer *on top of* the core references, including `../core/terminology.md`.
+
+Core `../core/terminology.md` already covers the MultiQC **name** (exact
+capitalization `MultiQC`; not "multiqc", "multiQC", or "multi-qc") and the
+general house rules. Don't duplicate those here — this file is for rules
+exclusive to MultiQC.
+
+> **Scaffold.** Populate from the MultiQC docs themselves — **do not invent**
+> module names, CLI flags, or product behavior; flag anything you can't confirm
+> (SKILL.md rule 8).
+
+## Feature and entity names
+
+<!-- Lowercase common nouns for MultiQC's own concepts (per the pattern in
+     ../core/terminology.md). Populate from MultiQC docs: e.g. module, report, sample,
+     general statistics table. -->
+
+_None confirmed yet._
+
+## Commands, flags, and config
+
+<!-- MultiQC-specific CLI command (`multiqc`), flags, and config keys, in backticks. -->
+
+_None confirmed yet._

.claude/skills/docs-deslop/references/products/nextflow.md

@@ -0,0 +1,38 @@
+# Nextflow (exclusive rules)
+
+Exclusive terminology and formatting rules for **Nextflow** docs, and for
+Nextflow code and concepts referenced inside other products' docs. These layer
+*on top of* the core references, including `../core/terminology.md`.
+
+Core `../core/terminology.md` already covers the Nextflow **name** (not "NextFlow",
+"next-flow", or lowercase "nextflow" in prose), nf-core (lowercase, hyphenated),
+the pipeline-vs-workflow distinction, run vs task vs process, and the `NXF_*`
+environment variables. Don't duplicate those here. The rules below are exclusive
+to Nextflow. Don't invent DSL behavior or directive names — flag anything you
+can't confirm (SKILL.md rule 8).
+
+## DSL terms
+
+Nextflow DSL keywords and concepts are code — write them in backticks, and use
+the term precisely:
+
+| Term       | Meaning                                                                 |
+| ---------- | ----------------------------------------------------------------------- |
+| `workflow` | The `workflow { }` block that composes processes                        |
+| `process`  | The `process { }` block that defines a task                             |
+| channel    | The async data structure connecting processes (`Channel` factory in code) |
+| operator   | A channel transformation (`map`, `collect`, `mix`, …)                   |
+| executor   | The backend that runs tasks (local, SLURM, AWS Batch, …)                |
+| directive  | A process setting (`cpus`, `memory`, `container`, …)                    |
+
+- ✅ "The `workflow` block wires processes together with channels."
+- ❌ "The pipeline block wires the pipeline steps together." (imprecise; "pipeline" is a Seqera Platform term — see `../core/terminology.md`)
+
+## Config and command-line conventions
+
+- `nextflow.config` — the pipeline configuration file (in backticks).
+- Config scopes are code: `process`, `params`, `docker`, `aws`, `tower`, and so on.
+- **Single vs double dash:** Nextflow core options take a single dash (`-resume`,
+  `-profile`, `-c`); pipeline parameters take two (`--input`, `--outdir`). Preserve
+  the exact dash count — it is a common and consequential error.
+- `params.<name>` in code corresponds to `--<name>` on the command line.

.claude/skills/docs-deslop/references/products/platform.md

@@ -0,0 +1,23 @@
+# Seqera Platform (exclusive rules)
+
+Exclusive terminology and formatting rules for **Seqera Platform** docs — Platform
+Cloud, Platform Enterprise, the CLI (`tw`), and the API. These layer *on top of*
+the core references, including `../core/terminology.md`.
+
+The core `../core/terminology.md` is already Platform-centric: it covers the product
+and tool names, lowercase feature nouns, pipeline vs workflow, run vs task vs
+process, bold vs backticks, the UI element names (**Launchpad**, **Data
+Explorer**, **Compute Envs**, …), and the `TOWER_*` environment variables. Apply
+all of that from core — do **not** duplicate it here.
+
+This file is for rules that are exclusive to Seqera Platform and go *beyond* the
+shared core terminology. There are none yet.
+
+## Platform-exclusive rules
+
+<!-- Add rules here that apply only to Seqera Platform and are not already in
+     ../core/terminology.md — for example, edition-specific wording (Cloud vs
+     Enterprise), or Platform UI/behavior details finer-grained than the core
+     UI-name list. Don't invent; flag unconfirmed terms (SKILL.md rule 8). -->
+
+_None yet._

.claude/skills/docs-deslop/references/products/wave.md

@@ -0,0 +1,26 @@
+# Wave (exclusive rules)
+
+Exclusive terminology and formatting rules for **Wave** docs (`wave_docs/`). These
+layer *on top of* the core references, including `../core/terminology.md`.
+
+Core `../core/terminology.md` already covers the Wave **name** (capitalized; the
+container provisioning service) and the general house rules. Don't duplicate
+those here — this file is for rules exclusive to Wave.
+
+> **Scaffold.** Populate from the Wave docs themselves — **do not invent** feature
+> names, CLI flags, or product behavior; flag anything you can't confirm
+> (SKILL.md rule 8). Fusion is often used alongside Wave — see `fusion.md`.
+
+## Feature and entity names
+
+<!-- Lowercase common nouns for Wave's own concepts (per the pattern in
+     ../core/terminology.md). Populate from Wave docs: e.g. container, build, freeze,
+     augmentation layer. -->
+
+_None confirmed yet._
+
+## Commands, flags, and config
+
+<!-- Wave-specific CLI commands, flags, and config keys, in backticks. -->
+
+_None confirmed yet._

.claude/skills/docs-structure/SKILL.md

@@ -31,17 +31,33 @@ Use this skill when:
 
 ## Formatting areas
 
-Each area has a reference file under `references/`. Read the reference for the
-area you're working on and apply its spec.
+References split into two tiers, mirroring `docs-deslop`: **core** conventions in
+`references/core/` apply to every product's docs; **product** conventions in
+`references/products/` differ by product (and some don't apply to every product).
+Read the reference for the area you're working on and apply its spec.
 
-| Area            | Reference                       | Covers                                                                        |
-| --------------- | ------------------------------- | ----------------------------------------------------------------------------- |
-| Prerequisites   | `references/prerequisites.md`   | The `:::info[**Prerequisites**]` admonition, lead-in, bullet phrasing         |
-| Troubleshooting | `references/troubleshooting.md` | Moving inline troubleshooting sections to the product's troubleshooting pages |
+**Core (universal — all products):**
+
+| Area                         | Reference                        | Covers                                                                        |
+| ---------------------------- | -------------------------------- | ----------------------------------------------------------------------------- |
+| Prerequisites                | `references/core/prerequisites.md`   | The `:::info[**Prerequisites**]` admonition, lead-in, bullet phrasing     |
+| Troubleshooting (identify + format) | `references/core/troubleshooting.md` | What counts as troubleshooting content, how to format an entry, the move process |
+
+**Product-specific (load the detected product's file):**
+
+| Area                     | Reference                          | Covers                                                                 |
+| ------------------------ | ---------------------------------- | ---------------------------------------------------------------------- |
+| Troubleshooting placement | `references/products/<product>.md` | **Where** troubleshooting goes for that product (destination, page-naming, existing-vs-new) — or that the product has none, so leave it inline |
+
+Troubleshooting spans both tiers: *identifying and formatting* an entry is
+universal (core); *where it goes* is product-specific (products). MultiQC and
+Nextflow have no troubleshooting destination in this repo — their product files
+say leave it inline.
 
 (More areas will be added over time — page introductions, admonition types,
 image/asset conventions, and so on. Add a row here and a reference file when you
-codify a new convention.)
+codify a new convention; put it in `core/` if it's universal, `products/` if it
+differs by product.)
 
 ## Process
 
@@ -50,14 +66,22 @@ codify a new convention.)
    change can't drop content it never saw.
 2. **Identify the in-scope region.** If the user pointed at a section or
    selection, format only that. Otherwise format the whole page.
-3. **Pick the relevant formatting areas** for what's in scope, and read each
-   area's reference file.
-4. **Apply each area's spec** with surgical Edits — touch only the region the
+3. **Detect the product** (only needed for product-specific areas like
+   troubleshooting placement). Use the same signals as `docs-deslop`: the file path
+   (`platform-cloud/`, `platform-enterprise_docs/`, `fusion_docs/`, `wave_docs/`,
+   `multiqc_docs/`, a Nextflow context), the user's statement, or the doc's
+   vocabulary. **When `docs-deslop` invokes this skill, it passes the product it
+   already detected — use that instead of re-detecting.** For a purely core area
+   (prerequisites), you can skip this.
+4. **Pick the relevant formatting areas** for what's in scope, and read each
+   area's reference file — the `core/` file always, plus the detected product's
+   `products/<product>.md` for placement.
+5. **Apply each area's spec** with surgical Edits — touch only the region the
    convention governs; leave the rest of the page byte-for-byte unchanged.
-5. **Preserve non-prose exactly**: frontmatter keys and machine-read values,
+6. **Preserve non-prose exactly**: frontmatter keys and machine-read values,
    code blocks, `import`/`export` lines, JSX/MDX components, links, and anchors.
    Never drop a link, anchor, or list item — only restructure.
-6. **Summarize**: name each formatting area you applied and the change made, and
+7. **Summarize**: name each formatting area you applied and the change made, and
    flag any judgment call (e.g. a heading rename that affects inbound anchors) for
    the user to confirm.