build: migrate Markdown tooling to rumdl

.agents/skills/create-lab-guide/SKILL.md

@@ -108,9 +108,8 @@ Use contractions ("it's", "you're", "don't").
 ## Step 5: Validate
 
 1. Confirm frontmatter has `title`, `description`, `keywords`, and `params.tags` including `labs`.
-2. Run `npx prettier --write <file>` to format.
+2. Run `npx --no-install rumdl fmt <file>` to format.
 3. Run `docker buildx bake lint vale` and fix any errors.
 4. Re-read the file and verify: correct shortcode syntax, objectives match source content, modules match `labspace.yaml`, no vendored paths edited.
 
 Do not proceed to commit until validation passes.
-

.agents/skills/testcontainers-guides-migrator/SKILL.md

@@ -350,8 +350,8 @@ If any test fails, debug and fix the code in both the temporary project AND the
 
 **IMPORTANT**: Run ALL validation locally before committing. Vale checks run on CI and will block the PR if they fail — fixing after push wastes CI cycles and review time.
 
-1. `npx prettier --write content/guides/testcontainers-{LANG}-{GUIDE_ID}/`
-2. `npx prettier --write content/manuals/testcontainers.md`
+1. `npx --no-install rumdl fmt content/guides/testcontainers-{LANG}-{GUIDE_ID}/`
+2. `npx --no-install rumdl fmt content/manuals/testcontainers.md`
 3. `docker buildx bake lint` — must pass with no errors
 4. `docker buildx bake vale` — then check for errors in the new files:
    ```bash

.agents/skills/write/SKILL.md

@@ -41,14 +41,14 @@ front matter. If any are missing from a file you touch, add them.
 
 ## 4. Validate
 
-Prettier runs automatically after each edit via the PostToolUse hook.
+rumdl runs automatically after each edit via the PostToolUse hook.
 Run lint manually after all edits are complete:
 
 ```bash
 scripts/lint.sh <changed-files>
 ```
 
-The lint script runs markdownlint and vale on only the files you pass it,
+The lint script runs rumdl and Vale on only the files you pass it,
 so the output is scoped to your changes. Fix any errors it reports.
 
 ## 5. Self-review

.agents/skills/write/scripts/post-edit.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # PostToolUse hook for Edit/Write in the write skill.
-# Auto-formats Markdown files with prettier after each edit.
+# Auto-formats Markdown files with rumdl after each edit.
 set -euo pipefail
 
 input=$(cat)
@@ -9,4 +9,4 @@ file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty')
 [ -z "$file_path" ] && exit 0
 [[ "$file_path" != *.md ]] && exit 0
 
-npx prettier --write "$file_path" 2>/dev/null
+npx --no-install rumdl fmt "$file_path" 2>/dev/null

.github/agents/docs-scanner.yaml

@@ -100,7 +100,7 @@ agents:
          - Broken or missing links → htmltest catches these; do not file
          - Time-relative words ("currently", "recently", "still", "yet",
            "new") with no broader context problem → Vale catches these
-         - Formatting or style problems → markdownlint/Vale catch these
+         - Formatting or style problems → rumdl/Vale catch these
       4. Is this a legitimate product feature gate? "Limited Access", "Contact
          your Docker account team to request access", "available on paid plans",
          "coming soon for Business subscribers" are product decisions, not stale
@@ -121,7 +121,7 @@ agents:
       - **Vague verification tasks** — "verify this diagram is up to date",
         "check these links are still valid" — if you cannot identify the
         specific problem from reading the file, don't file
-      - **Style and formatting** — Vale and markdownlint handle these
+      - **Style and formatting** — Vale and rumdl handle these
       - **Suspicions without evidence** — you must quote the specific wrong text
 
       ## Filing issues

.github/labeler.yml

@@ -32,7 +32,7 @@ area/tests:
   - changed-files:
       - any-glob-to-any-file:
           - .htmltest.yml
-          - .markdownlint.json
+          - .rumdl.toml
           - .vale.ini
           - _vale/**
           - hack/test/*

.prettierignore

@@ -0,0 +1 @@
+**/*.md

.rumdl.toml

@@ -0,0 +1,44 @@
+[global]
+flavor = "hugo"
+enable = [
+  "MD011",
+  "MD018",
+  "MD019",
+  "MD020",
+  "MD021",
+  "MD022",
+  "MD023",
+  "MD025",
+  "MD026",
+  "MD029",
+  "MD035",
+  "MD037",
+  "MD038",
+  "MD039",
+  "MD040",
+  "MD042",
+  "MD052",
+  "MD055",
+  "MD056",
+  "MD059",
+]
+exclude = [
+  "content/manuals/desktop/previous-versions/*.md",
+  "content/manuals/engine/release-notes/*.md",
+]
+
+[MD029]
+style = "one_or_ordered"
+
+[MD052]
+shortcut-syntax = false
+
+[MD059]
+prohibited-texts = [
+  "click here",
+  "here",
+  "link",
+  "more",
+  "learn more",
+  "find out more",
+]

AGENTS.md

@@ -5,7 +5,7 @@ This site builds https://docs.docker.com/ using Hugo.
 
 ## Project structure
 
-```
+```text
 content/          # Documentation source (Markdown + Hugo front matter)
 ├── manuals/      # Product docs (Engine, Desktop, Hub, etc.)
 ├── guides/       # Task-oriented guides
@@ -119,7 +119,7 @@ Every content page under `content/` requires:
 
 - `title:` — page title
 - `description:` — short description for SEO/previews
-- `keywords:` — list of search keywords (omitting this fails markdownlint)
+- `keywords:` — list of search keywords
 
 Additional common fields:
 
@@ -135,8 +135,9 @@ produces broken HTML — always check COMPONENTS.md for correct syntax.
 ## Commands
 
 ```sh
-npx prettier --write <file>        # Format before committing
-scripts/lint.sh <file>...          # Lint specific files (markdownlint + vale)
+npx --no-install rumdl fmt <file>  # Format Markdown before committing
+npx prettier --write <file>        # Format non-Markdown files
+scripts/lint.sh <file>...          # Lint specific files (rumdl + Vale)
 docker buildx bake validate        # Run all validation checks
 docker buildx bake lint            # Markdown linting only
 docker buildx bake vale            # Style guide checks only
@@ -157,7 +158,7 @@ and `validate-vendor` targets run correctly in CI.
 ## Verification loop
 
 1. Make changes
-2. Format with prettier: `npx prettier --write <file>`
+2. Format Markdown with rumdl: `npx --no-install rumdl fmt <file>`
 3. Lint the changed files: `scripts/lint.sh <file>...`
 4. Run a full build with `docker buildx bake` (optional for small changes)
 

Dockerfile

@@ -61,12 +61,8 @@ RUN --mount=type=cache,target=/tmp/hugo_cache \
 RUN ./hack/flatten-and-resolve.js public
 
 # lint lints markdown files
-FROM ghcr.io/igorshubovych/markdownlint-cli:v0.45.0 AS lint
-RUN --mount=type=bind,target=. \
-    markdownlint \
-    "content/**/*.md" \
-    --ignore "content/manuals/engine/release-notes/*.md" \
-    --ignore "content/manuals/desktop/previous-versions/*.md"
+FROM ghcr.io/rvben/rumdl:0.2.49-alpine AS lint
+RUN --mount=type=bind,target=. rumdl check content
 
 # test validates HTML output and checks for broken links
 FROM wjdp/htmltest:v${HTMLTEST_VERSION} AS test

content/get-started/docker-concepts/the-basics/what-is-a-container.md

@@ -57,7 +57,7 @@ Use the following instructions to run a container.
 
 2. Specify `welcome-to-docker` in the search input and then select the **Pull** button.
 
-    ![A screenshot of the Docker Desktop Dashboard showing the search result for welcome-to-docker Docker image ](images/search-the-docker-image.webp?border=true&w=1000&h=700)
+    ![A screenshot of the Docker Desktop Dashboard showing the search result for welcome-to-docker Docker image](images/search-the-docker-image.webp?border=true&w=1000&h=700)
 
 3. Once the image is successfully pulled, select the **Run** button.
 

content/guides/java.md

@@ -597,7 +597,7 @@ To start your debug session, select the **Run** menu and then **Debug _NameOfYou
 
 You should now see the connection in the logs of your Compose application.
 
-![Compose log file ](images/java-compose-logs.webp)
+![Compose log file](images/java-compose-logs.webp)
 
 You can now call the server endpoint.
 

content/guides/localstack.md

@@ -65,11 +65,11 @@ Launch a quick demo of LocalStack by using the following steps:
 
    This Compose file also includes specifications for a required Mongo database. You can verify the services are up and running by visiting the Docker Desktop Dashboard.
 
-   ![Diagram showing the LocalStack and Mongo container up and running on Docker Desktop ](./images/launch-localstack.webp)
+   ![Diagram showing the LocalStack and Mongo container up and running on Docker Desktop](./images/launch-localstack.webp)
 
 3. Verify that LocalStack is up and running by selecting the container and checking the logs.
 
-   ![Diagram showing the logs of LocalStack container ](./images/localstack-logs.webp)
+   ![Diagram showing the logs of LocalStack container](./images/localstack-logs.webp)
 
 4. Creating a Local Amazon S3 Bucket
 
@@ -91,7 +91,7 @@ Launch a quick demo of LocalStack by using the following steps:
 
     You can verify if the S3 bucket gets created or not by selecting the LocalStack container on the Docker Desktop Dashboard and viewing the logs. The logs indicates that your LocalStack environment is configured correctly and you can now use the `mysamplebucket` for storing and retrieving objects.
 
-    ![Diagram showing the logs of LocalStack that highlights the S3 bucket being created successfully ](./images/localstack-s3put.webp)
+    ![Diagram showing the logs of LocalStack that highlights the S3 bucket being created successfully](./images/localstack-s3put.webp)
 
 ## Using LocalStack in development
 
@@ -102,7 +102,7 @@ Now that you've familiarized yourself with LocalStack, it's time to see it in ac
 - MongoDB: A database to store all the to-do list data
 - LocalStack: Emulates the Amazon S3 service and stores and retrieve images.
 
-![Diagram showing the tech stack of the sample todo-list application that includes LocalStack, frontend and backend services ](images/localstack-arch.webp)
+![Diagram showing the tech stack of the sample todo-list application that includes LocalStack, frontend and backend services](images/localstack-arch.webp)
 
 
 ## Connecting to LocalStack from a non-containerized app

content/guides/ruby.md

@@ -506,12 +506,12 @@ $ docker exec -it docker-ruby-on-rails-web-1 rake db:migrate RAILS_ENV=test
 
 You will see a similar message like this:
 
-`console
+```console
 == 20240710193146 CreateWhales: migrating =====================================
 -- create_table(:whales)
    -> 0.0126s
 == 20240710193146 CreateWhales: migrated (0.0127s) ============================
-`
+```
 
 Refresh <http://localhost:3000> in your browser and add the whales.
 

content/guides/wiremock.md

@@ -57,12 +57,12 @@ Launch a quick demo of WireMock by using the following steps:
 
     After a moment, the application will be up and running. 
 
-    ![Diagram showing the WireMock container running on Docker Desktop ](./images/wiremock-using-docker.webp)
+    ![Diagram showing the WireMock container running on Docker Desktop](./images/wiremock-using-docker.webp)
 
 
     You can check the logs by selecting the `wiremock-node-docker` container:
 
-    ![Diagram showing the logs of WireMock container running on Docker Desktop ](./images/wiremock-logs-docker-desktop.webp)
+    ![Diagram showing the logs of WireMock container running on Docker Desktop](./images/wiremock-logs-docker-desktop.webp)
 
  4. Test the Mock API.
 
@@ -93,7 +93,7 @@ Now that you have tried WireMock, let’s use it in development and testing. In
   - External AccuWeather API: The real API from which live weather data is fetched.
   - WireMock: The mock server that simulates the API responses during testing. It runs as a Docker container.
 
-  ![Diagram showing the architecture of WireMock in development ](./images/wiremock-arch.webp)
+  ![Diagram showing the architecture of WireMock in development](./images/wiremock-arch.webp)
 
   - In development, the Node.js backend sends a request to WireMock instead of the actual AccuWeather API.
   - In production, it connects directly to the live AccuWeather API for real data.

content/manuals/engine/swarm/how-swarm-mode-works/services.md

@@ -32,7 +32,7 @@ For example, imagine you want to load balance between three instances of an HTTP
 listener. The diagram below shows an HTTP listener service with three replicas.
 Each of the three instances of the listener is a task in the swarm.
 
-![ HTTP listener service with three replicas](../images/services-diagram.webp?w=550)
+![HTTP listener service with three replicas](../images/services-diagram.webp?w=550)
 
 A container is an isolated process. In the Swarm mode model, each task invokes
 exactly one container. A task is analogous to a “slot” where the scheduler

docs_engineer.yml

@@ -122,7 +122,7 @@ agents:
         <validation>
         - Use the validate tool to verify your changes
         - Check specific targets: lint, vale, test, unused-media
-        - Fix markdownlint errors in content files
+        - Fix rumdl errors in content files
         - Fix htmltest errors (broken links, missing alt text)
         - Validate redirects with test-go-redirects
         </validation>

hack/sbx-release-notes.py

@@ -135,7 +135,7 @@ def shift_headings(body: str) -> str:
 
 
 def normalize_body(body: str) -> str:
-    """Fix markdownlint issues in release body content:
+    """Fix Markdown lint issues in release body content:
     - Ensure a blank line follows each heading (MD022).
     - Add 'console' language tag to fenced code blocks that have none (MD040).
     Safe to run on content that already complies — no double blank lines are added."""
@@ -203,7 +203,7 @@ def main() -> None:
     generated = TEMPLATE.render(releases=releases)
     splice(file, generated)
     if shutil.which("npx"):
-        subprocess.run(["npx", "--no-install", "prettier", "--write", str(file)], check=False)
+        subprocess.run(["npx", "--no-install", "rumdl", "fmt", str(file)], check=False)
     print(f"Wrote {len(releases)} releases (latest {args.minor_releases} minor releases) to {file}")
 
 

layouts/_shortcodes/file.html

@@ -3,7 +3,7 @@
 
   The body must be a fenced code block. The fence's info string is used as
   the syntax-highlighting language. Wrapping the body in a fence keeps
-  markdownlint and Vale happy (they treat fence content as code and skip
+  rumdl and Vale happy (they treat fence content as code and skip
   lint rules that would otherwise fire on `#` comment lines).
 
   Usage: