Review Changelog

Analyze commits since the last release tag, draft bilingual changelog entries, and guide the version bump workflow.

Changelog Files

Both files must always be updated together with matching content.

Workflow

1. Identify the last release tag and current version

   git describe --tags --abbrev=0
   node -p "require('./package.json').version"
   

2. List commits since last tag

   git log <last-tag>..HEAD --oneline --no-merges
   

   If no commits exist, report "Changelog is up-to-date" and stop.

3. Read current changelogs to understand existing format and the latest entry structure.

4. Categorize commits into:

   • 新功能 / New Features — new user-facing functionality
   • 修復 / Fixes — bug fixes
   • 改進 / Improvements — enhancements to existing features
   • 重構 / Refactor — code structure changes
   • 效能 / Performance — performance optimizations
   • 文件 / Documentation — docs-only changes
   • 測試 / Testing — test infrastructure or new tests
   • Skip commits that are changelog/version bumps themselves.

5. Determine version bump type

   • patch: bug fixes, minor improvements, docs, tests
   • minor: new features, significant UI changes
   • major: breaking changes (rare)

6. Draft bilingual entries in zh-TW and English. Follow the existing format:

   ## v{version}
   
   _YYYY-MM-DD_
   
   ### 新功能
   - **Area**: Description
   
   ### 修復
   - **Area**: Description
   

   Use today's date. Match the style of existing entries (bold area prefix, concise descriptions).

7. Present report in zh-TW to the user:

   • Proposed version bump type with rationale
   • Draft changelog entries (both languages)
   • List of commits mapped to categories
   • Ask user to confirm or adjust

8. After confirmation, execute in order:

   1. Edit website/changelog.md — insert new version section after the header
   2. Edit website/en/changelog.md — insert matching English section
   3. Stage and commit changelog files: docs: update changelog for v{version}
   4. Run npm version <patch|minor|major> (creates git tag automatically)
   5. Report the new version and tag

Version History Structure Rule

Only the two most recent minor versions keep detailed per-patch entries. When a new minor version is introduced, condense the oldest of the two into the "Earlier Versions" summary section at the bottom of each changelog file.