change-log

name: change-log description: Generate a full, user-facing changelog for the current in-development app version by comparing with the previous release tag (including uncommitted changes), and update the appropriate CHANGELOG.md accordingly.

Goal

Produce a complete, user-facing changelog for the current in-development app version and update the appropriate CHANGELOG.md accordingly.

When to use

• You need to generate or refresh the changelog for the current dev version.
• The summary must include all changes since the previous release tag, including uncommitted work.

Inputs and sources

• App version (heuristic):
  1. crates/app/tauri.conf.json (version).
  2. packages/tauri/src-tauri/tauri.conf.json (version).
  3. tauri.conf.json (repo root or first match via search).
  4. package.json (version) as a fallback when no Tauri config exists.
• Previous release tag: the latest reachable release tag in git history.
• Changes since tag: commit logs + file diffs + uncommitted working tree changes.
• Changelog file (heuristic):
  1. crates/app/CHANGELOG.md.
  2. CHANGELOG.md at repo root.
  3. packages/tauri/CHANGELOG.md or packages/app/CHANGELOG.md if present.

Workflow

1. Read the current app version using the heuristic order above. This is the target section in the changelog.
2. Identify the previous release tag.
   • Preferred: git describe --tags --abbrev=0.
   • If ambiguous or no tag is found, list tags with git tag --sort=-creatordate and ask the user to pick the correct release tag.
3. Collect the full change set (including uncommitted changes).
   • Commit log: git log <tag>..HEAD --reverse.
   • File-level changes: git log <tag>..HEAD --name-status.
   • Diff for details: git diff <tag>..HEAD.
   • Uncommitted changes: git status --porcelain, git diff, git diff --staged.
4. Summarize changes into user-facing items only.
   • Include only changes that impact users (features, UI, behavior, fixes).
   • Exclude internal-only work (tests, refactors without behavior change, tooling, CI, internal-only docs).
5. Update the selected CHANGELOG.md.
   • If the target version section already exists, replace it with a full, up-to-date section. Each invocation must be a full refresh for that version.
   • Keep the version order descending (newest first) and follow the existing formatting style.

Categorization rules

Use these sections in this order and omit any empty section:

1. Added
2. Changed
3. Fixed

Guidance:

• Added: new capabilities, new screens, new features users can now use.
• Changed: behavior or UX changes, settings changes, performance improvements users can notice.
• Fixed: bug fixes or incorrect behavior users might have experienced.
• If a change cannot be clearly categorized, ask the user to choose the section.

Highlight rule

If there is a major milestone or standout feature, add a short highlight paragraph directly under the version header and above any section headers.

Output format

Follow the existing Markdown style in the selected CHANGELOG.md.

Example skeleton:

## 0.0.x

A short highlight paragraph (only if truly major).

### Added

- User-facing addition.

### Changed

- User-facing change.

### Fixed

- User-facing fix.

Links

Use Markdown links if an item needs more explanation. The update dialog supports links.

Notes

• Always include uncommitted changes in the summary. If the inclusion is uncertain, confirm with the user.
• Do not invent changes. Every bullet must be traceable to the collected logs/diffs.