1. Detect the new version (from package.json, git tag, or ask the user).
2. Run git diff <last_tag>..HEAD and git log <last_tag>..HEAD --oneline to gather raw changes.
3. Ask the user clarifying questions (see Workflow).
4. Categorize changes into: Added, Changed, Fixed, Deprecated, Removed, Security.
5. Insert a new version block at the top of CHANGELOG.md (below [Unreleased] if present).

Progress:

• Step 1: Identify current version and previous release tag/commit
• Step 2: Gather git evidence (diff + log)
• Step 3: Ask the user targeted questions
• Step 4: Draft categorized entries
• Step 5: Write/update CHANGELOG.md
• Step 6: Show the diff of the changelog file to the user for approval

Step 1: Identify version

• Look for a version file (package.json, pyproject.toml, VERSION) or ask: "What version are you publishing? (e.g. 1.3.0)"
• Find the previous tag: git describe --tags --abbrev=0 (fallback: ask user or use first commit).

Step 2: Gather git evidence

Run and read, don't just summarize blindly:

git log <prev_tag>..HEAD --oneline
git diff <prev_tag>..HEAD --stat
git diff <prev_tag>..HEAD

Use the diff to understand what actually changed (files, functions, logic), not just commit message text — commit messages are often vague or wrong.

Step 3: Ask the user

Ask concise, specific questions based on what the diff shows. Don't ask generic questions — reference the actual changes found. Examples:

• "I see changes in cart.js and a new Cart model — is this the new 'persistent shopping cart' feature? How would you describe it to a user?"
• "I see a price calculation change in products.js — was this a bug fix? What was wrong (e.g., wrong price for an item)?"
• "Any breaking changes, deprecations, or security fixes I should highlight?"
• "Is this release public-facing (customers see it) or internal-only?"

Keep it to 3-5 questions max. Infer as much as possible from the diff first so you don't ask about things you can already tell.

Step 4: Draft categorized entries

Map to standard categories:

• Added — new features
• Changed — changes to existing functionality
• Fixed — bug fixes
• Deprecated — soon-to-be removed features
• Removed — removed features
• Security — vulnerability fixes

Write entries in plain, user-facing language, one line per change, imperative or past tense, consistent across the file. Reference issue/PR numbers if available in commits.

Step 5: Write CHANGELOG.md

If the file doesn't exist, create it with this header:

Markdown
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

Insert the new version block right after the header (or after [Unreleased] if present):

Markdown
undefined

Example 1: Input: Version 1.3.0. Git diff shows new Cart model + cart.js routes, and a fixed unit price constant in products.js (cucumber price corrected from wrong value). Output:

Markdown
undefined