diff --git a/.agents/skills/prepare-providers-documentation/SKILL.md b/.agents/skills/prepare-providers-documentation/SKILL.md
index b2e8a20c40db3..62c9819392cca 100644
--- a/.agents/skills/prepare-providers-documentation/SKILL.md
+++ b/.agents/skills/prepare-providers-documentation/SKILL.md
@@ -511,6 +511,27 @@ Rules:
   indent, double backticks).
 - Subjects must be the original commit subject with backticks replaced by
   single quotes (matches `message_without_backticks`). Don't paraphrase.
+- **Exception — collapse within-wave "add then rename/rework" chains into one
+  net entry.** When several pending commits are steps toward *one* net change —
+  a feature added in one PR and renamed or reworked in a later PR, both since
+  the last release (the released-only situation from Phase 3) — do **not** list
+  the intermediate steps as separate entries. A reader who never saw the
+  released intermediate form gets no context from ``Add X listener (#a)`` under
+  Features plus ``Rename X to Y (#b)`` under Misc. Write a **single** entry that
+  describes the **net user-facing change** and references **all** related PRs,
+  placed in the section of the most-impactful step. Real example: #68082 added
+  a Kafka listener and #70014 renamed it to the Kafka Event Producer in the same
+  wave → ``Add Kafka Event Producer publishing DagRun and TaskInstance
+  state-change events (#68082, #70014)`` under Features (and *no* separate Misc
+  "Rename …" line). This is the changelog counterpart of the unreleased-feature
+  classification rule: classify the rename as non-breaking (Phase 3) **and**
+  describe only what shipped, naming every PR involved.
+- **Capitalize the first letter of every entry**, not only after stripping a
+  Conventional Commit prefix. Contributors sometimes write a lowercase subject
+  (`derive keycloak oauth redirect_uri …`) or a pseudo-scope
+  (`cncf-kubernetes: fix …`); the changelog convention is a leading capital, so
+  render them as ``Derive keycloak oauth redirect_uri …`` /
+  ``Cncf-kubernetes: fix …``.
 - **Strip Conventional Commit prefixes** before writing to the changelog.
   If the subject starts with a prefix like `feat:`, `fix:`, `chore:`,
   `docs:`, `refactor:`, `ci:`, `test:`, `perf:`, `build:`, or `style:`
@@ -519,7 +540,17 @@ Rules:
   Example: `refactor: Fix _is_http_client_closed ...` →
   `Fix _is_http_client_closed ...`. Airflow does not use Conventional
   Commits and these prefixes should not appear in changelogs.
-- Always keep the `(#NNNN)` PR suffix.
+- **Send no-PR release-tooling commits to the excluded block**, even when the
+  Phase 1 deterministic classifier labeled them `documentation`. Subjects like
+  ``Prepare … providers release/documentation …`` and ``Hide non-user-facing
+  entries from ad-hoc provider release notes`` (often with no `(#NNNN)` suffix
+  because they were committed directly) are release plumbing, not user-facing
+  changes — a `(#NNNN)`-less line in a visible section reads as a mistake. Put
+  them under the `.. Below changes are excluded …` block. breeze's deterministic
+  classification can even be inconsistent for the same commit across providers,
+  so normalize to excluded.
+- Always keep the `(#NNNN)` PR suffix (or, for a collapsed chain, the
+  comma-separated list of all involved PRs).
 
 #### 4c. Regenerate templates with breeze
 
@@ -616,6 +647,14 @@ provider-by-provider:
   *"Provider dependency version bumps detected that should only be performed
   by Release Managers!"*. `git diff` the changed `pyproject.toml` files for
   `apache-airflow-providers-*` `>=` changes and list them for the RM.
+- **Scan the new changelog sections for three entry defects** — grep the lines
+  you added: (1) a bullet whose text starts with a lowercase letter → capitalize
+  it (Phase 4b); (2) a bullet in a *visible* section (Features / Bug Fixes /
+  Misc / Doc-only) with no `(#NNNN)` suffix → usually no-PR release-tooling that
+  belongs in the excluded block (Phase 4b); (3) an "add then rename" pair for
+  the same feature left as two separate entries → collapse into one net entry
+  naming both PRs (Phase 4b). Reviewers reliably catch all three, so fix them
+  before handing off.
 - Flag anything where Phase 3.5 had to escalate, so the RM can double-check.
 
 Stop here. Do not commit, do not push — the release manager opens the PR