docs: tighten the copy on the new pages

- state the positioning as a plain sentence instead of a bold colon reveal
- drop rhetorical setups, a metaphor kicker and mid-sentence bold
- give inanimate subjects human-free verbs; active voice where it was passive

Author: shenxianpeng

docs/blog/posts/2026-09-12-moving-to-cpp-linter.md

@@ -17,8 +17,7 @@ authors:
 A common C++ workflow on GitHub has two lint jobs that grew up separately: a format check that
 fails the build, and a clang-tidy job that posts review comments. They pin different clang
 versions, they run on different triggers, and when one of them starts flaking nobody remembers why
-it was configured that way. This post walks through replacing both with one cpp-linter-action step,
-and what changes for contributors.
+it was configured that way. Both jobs can be one cpp-linter-action step.
 
 <!-- more -->
 
@@ -52,7 +51,7 @@ jobs:
 
 The format job fails with a diff in the log; the tidy job builds a Docker image, runs, uploads an
 artifact, and a second workflow posts the review. Contributors see a red check for formatting and a
-review for clang-tidy, and format fixes still have to be made by hand.
+review for clang-tidy, and still fix the formatting by hand.
 
 ## The replacement
 
@@ -108,14 +107,14 @@ every push instead of adding a new one.
 
 ## Adopting a strict `.clang-tidy` on an old code base
 
-The usual reason teams keep clang-tidy out of pull requests is the first run: thousands of
-findings in files nobody is touching. Two inputs handle that:
+Teams usually keep clang-tidy out of pull requests because of the first run, which reports
+thousands of findings in files nobody is touching. Two inputs handle that:
 
 - `files-changed-only: true` (the default) limits analysis to files in the pull request.
 - `lines-changed-only: true` limits reported clang-tidy findings to lines the pull request changed.
 
-With both set, a pull request only hears about the code it wrote. The rest of the tree gets cleaned
-up gradually, or in a dedicated pass with the `cpp-linter` CLI.
+With both set, contributors only see findings on the lines they changed. You clean up the rest of
+the tree gradually, or in one pass with the `cpp-linter` CLI.
 
 ## What contributors see
 

docs/blog/posts/2026-09-12-one-clang-version-everywhere.md

@@ -26,8 +26,8 @@ whatever clang happens to be around.
 
 <!-- more -->
 
-This is the problem the cpp-linter tools are built around: **pick one LLVM major version and use it
-in every place code gets checked**.
+The cpp-linter tools are built to pick one LLVM major version and use it in every place code gets
+checked.
 
 ## Pick the version once
 
@@ -59,7 +59,7 @@ repos:
 ```
 
 `--style=file` and `--checks=.clang-tidy` read the same `.clang-format` and `.clang-tidy` files
-that CI will use, so there is one source of truth for the rules as well as for the version.
+that CI will use, so the rules, like the version, are defined in one place.
 
 ## CI: cpp-linter-action
 
@@ -149,10 +149,10 @@ When LLVM 22 is the version you want:
 If the action reports differences at this point, the two tools are not on the same version, and
 the numbers above are the first thing to check.
 
-## Why this matters more for clang-tidy
+## clang-tidy drifts more than clang-format
 
-`clang-format` version drift produces noisy diffs. `clang-tidy` version drift produces *different
-findings*: checks that were added, renamed or made stricter. A pull request that passes locally and
-fails in CI with a check nobody has heard of is usually a version mismatch, not a code problem.
-Pinning the same major version in the hook and in the action turns "why does CI complain" into a
-deterministic question.
+`clang-format` version drift produces noisy diffs. `clang-tidy` version drift produces different
+findings: checks that were added, renamed or made stricter. A pull request that passes locally and
+fails in CI with a check nobody has heard of is usually a version mismatch. With the hook and the
+action pinned to the same major version, the two numbers to compare are `--version` in
+`.pre-commit-config.yaml` and `version` in the workflow.

docs/showcase.md

@@ -7,8 +7,8 @@ description: Open-source projects that run cpp-linter-action and cpp-linter-hook
 
 <!-- markdownlint-disable MD033 -->
 
-More than **550 public repositories** run [cpp-linter-action](https://github.com/cpp-linter/cpp-linter-action)
-from a workflow on their default branch, with **over 87,000 GitHub stars** between them.
+More than 550 public repositories run [cpp-linter-action](https://github.com/cpp-linter/cpp-linter-action)
+from a workflow on their default branch, with over 87,000 GitHub stars between them.
 The list below is the top of that set, ranked by stars.
 
 !!! info "How this list is built"
@@ -65,7 +65,7 @@ shows the live list.
 
 ## Add your project
 
-Using cpp-linter in a public project? Open a pull request against
+To add a public project, open a pull request against
 [cpp-linter.github.io](https://github.com/cpp-linter/cpp-linter.github.io/edit/main/docs/showcase.md)
 and add a row, or mention it in
-[GitHub Discussions](https://github.com/cpp-linter/cpp-linter/discussions) and we will add it for you.
+[GitHub Discussions](https://github.com/cpp-linter/cpp-linter/discussions) and we will add it.

docs/why-cpp-linter.md

@@ -6,11 +6,11 @@ description: How cpp-linter compares with other clang-format and clang-tidy GitH
 # Why cpp-linter?
 
 There are several ways to run `clang-format` and `clang-tidy` on a pull request. Most of them do
-one tool, in one place, with whatever clang version the runner happens to have. cpp-linter is built
-around a different idea: **one pinned LLVM version, both tools, every place code gets checked**,
-from a contributor's pre-commit hook to the review comments on the pull request.
+one tool, in one place, with whatever clang version the runner happens to have. cpp-linter pins one
+LLVM version and runs both tools in every place code gets checked, from a contributor's pre-commit
+hook to the review comments on the pull request.
 
-## The short version
+## What you get
 
 - **Both tools in one step.** `clang-format` and `clang-tidy` run from a single
   `cpp-linter/cpp-linter-action@v2` step. The other actions in the table below do one or the other.
@@ -52,10 +52,9 @@ links to verify a cell. ✓ yes · ✗ no · — not applicable.
 
 <!-- markdownlint-enable MD013 MD033 -->
 
-If you maintain one of these projects and a cell is out of date, please
-[open an issue](https://github.com/cpp-linter/cpp-linter.github.io/issues/new) or edit this page;
-we will correct it. The point of the table is to help people pick the right tool, not to rank
-projects.
+The table is there to help people pick a tool. If you maintain one of these projects and a cell is
+out of date, [open an issue](https://github.com/cpp-linter/cpp-linter.github.io/issues/new) or
+edit this page and we will correct it.
 
 [reviewdog](https://github.com/reviewdog/reviewdog) is not in the table because it is a reporting
 framework rather than a linter: it has no built-in clang-format or clang-tidy support and needs a