feat: add update-changelog skill documentation

.github/skills/update-changelog/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: update-changelog
+description: 'Update docs/CHANGELOG.md from git history, GitHub releases, and code diffs. Use when: writing release notes, syncing the latest changelog entry, summarizing a new tag, or keeping changelog wording concise and consistent.'
+argument-hint: 'Describe the target, for example: latest version only'
+---
+
+# Update Changelog
+
+Update `docs/CHANGELOG.md` from repository evidence instead of guesswork.
+
+## When to Use
+
+- Add the newest release entry to `docs/CHANGELOG.md`
+- Sync changelog text with GitHub Releases
+- Summarize the latest tag from git history or code diffs
+
+## Defaults
+
+- Keep the wording brief
+- Only add the latest missing version unless the user explicitly asks to backfill older releases
+- Prefer GitHub sources first, especially Releases and tag metadata
+- Skip `Features` / `Improvements` / `Bug Fixes` headings when the release only has a few clear items
+
+## Procedure
+
+### 1. Read the local style
+
+- Open `docs/CHANGELOG.md`
+- Match the existing tone, bullet style, section ordering, and date format
+
+### 2. Determine the target release
+
+- Read the root `package.json` version and compare it with the top changelog entry
+- Find the previous tag for the target version
+- If the latest version is already documented, stop and report that no changelog update is needed
+
+### 3. Gather evidence
+
+Prefer these sources in order:
+
+1. GitHub release notes
+
+```bash
+GH_PAGER=cat gh release view v<version> --repo <owner>/<repo> --json tagName,name,publishedAt,body
+```
+
+2. Tag date
+
+```bash
+git log -1 --format=%cs v<version>
+```
+
+3. Commit history between tags
+
+```bash
+git --no-pager log --format='%h %s' --no-merges v<previous>..v<version>
+```
+
+4. Diff scope when commit subjects are vague
+
+```bash
+git --no-pager diff --name-only v<previous>..v<version>
+git --no-pager diff --stat v<previous>..v<version>
+```
+
+5. Read touched files directly only when the user-visible change is still unclear
+
+### 4. Distill what belongs in the changelog
+
+Include:
+
+- User-visible features
+- Important behavior changes
+- Bug fixes that improve reliability, compatibility, or developer experience
+- Small docs updates only when they materially change supported setups or onboarding
+
+Exclude unless explicitly requested:
+
+- Pure version bumps
+- Routine dependency updates
+- Internal refactors with no visible impact
+- Mechanical formatting noise
+
+### 5. Choose the structure
+
+- If the release has 1 to 3 clear points, write flat bullets directly under the version heading
+- If the release has several distinct items, use short headings such as `### Features`, `### Improvements`, and `### Bug Fixes`
+- Do not force categories when they make the entry longer or noisier
+
+### 6. Write the entry
+
+- Add or update only the requested release entry
+- Keep bullets short and concrete
+- Reuse project terminology from nearby entries
+- Avoid marketing language
+- Do not copy noisy GitHub release text verbatim
+
+### 7. Verify
+
+- Check dates, version numbers, and tag boundaries
+- Ensure Markdown structure matches nearby entries
+- Confirm no intermediate versions were added unless requested
+
+## Completion Checks
+
+- The newest requested version is documented
+- The wording is concise and consistent with the surrounding changelog
+- The entry is backed by GitHub releases, git history, or code diff evidence
+- Low-signal internal changes were left out