docs(skill): narrow the ISO claim and correct the grep description

Review fixes. The bolded lead read as an absolute while the body reported 363
DD-MM-YYYY headings and told you to match the file — it now says "most", and
says outright that a DD-MM-YYYY file stays DD-MM-YYYY. The counts are stamped
as of 2026-08-25 so a future reader knows they are a snapshot.

CodeRabbit is right that `grep -q "^## ${version} ("` is not an exact-version
check. Reproduced: with version 5.1.1.2 the pattern matches a heading reading
`## 5X1Y1Z2 (`, because BRE dots match any character; `grep -qF` does not.
Described as an unescaped BRE instead. The conclusion is unchanged, since the
date is not in the pattern either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/skills/hassio-addon-workflow/SKILL.md

@@ -169,7 +169,9 @@ CI gates on a PR: **`CHANGELOG.md` updated** (hard fail), the **HA add-on linter
 (`frenck/action-addon-linter`, blocking — not the weekly Super-Linter, which is non-blocking), and
 the **add-on image build**. Bump `version` anyway (`X.Y.Z.N`, never `X.Y.Z-N`, see
 `references/traps.md#versioning`) — Supervisor won't offer a rebuild without it. Update
-`README.md` if you added options; match the CHANGELOG heading format `## X.Y (DD-MM-YYYY)`.
+`README.md` if you added options; write the CHANGELOG heading as `## <version> (<date>)`,
+matching the date format already in that file — almost always ISO `YYYY-MM-DD`, see
+`references/traps.md#ci-and-review-bots`.
 
 Write the body to a file, `gh pr create --body-file`: state what was measured, what changed,
 **what is not verified**, and how to roll back the riskiest hunk alone.

.claude/skills/hassio-addon-workflow/references/traps.md

@@ -241,6 +241,18 @@ account. Note it and move on rather than guessing.
 **Resolving a review thread requires GraphQL** (`resolveReviewThread`); the REST API cannot do it.
 `scripts/pr_review.sh` wraps fetch / reply / resolve.
 
+**Most CHANGELOG heading dates are ISO, whatever the bots' defaults say.** Match the format
+already in the add-on's file — a `DD-MM-YYYY` file stays `DD-MM-YYYY`. Where you have no
+precedent, ISO is the house style: as of 2026-08-25, `## <version> (YYYY-MM-DD)` accounts for
+7705 dated headings against 363 in `DD-MM-YYYY`, and the newest entry is ISO in 125 of 135
+add-ons. Copilot flags an ISO file that gets a `DD-MM-YYYY` entry (#3019). `DD-MM-YYYY` is not
+invented — it is what `onpush_builder.yaml` writes with `date '+%d-%m-%Y'` when it has to insert
+a heading you forgot, and what the addons_updater bot writes when its `date_iso8601` option is
+off (`99-run.sh`; it is on in production here) — but neither is a reason to write it yourself.
+The builder's duplicate check is `grep -q "^## ${version} ("` — an unescaped BRE, so the dots in
+a version match any character, and it does not look at the date at all. Either way an ISO heading
+you wrote yourself still suppresses the bot's insertion.
+
 **The repo's `.markdownlint.yaml` does not disable MD022/MD032**, so a CHANGELOG will show
 dozens of pre-existing heading/list findings. They are noise because lint is `continue-on-error`,
 not because the config exempts them — don't cite the config as a reason to ignore a finding.