Update Changelog

Update CHANGELOG.md with user-facing changes from recent development work.

Input

Primary input: optional start reference — a date (YYYY-MM-DD) or commit hash.

Optional last parameter: -- <additional context>

Interpret $ARGUMENTS as one of:

• <date>

• <commit>

• <date> -- <additional context>

• <commit> -- <additional context>

• -- <additional context>

If no start reference is provided, look at commits since the last changelog update. Use any additional context to influence grouping, emphasis, or release framing.

Process

Step 1: Read Current Changelog

Read CHANGELOG.md to understand the existing format and last update.

Step 2: Gather Recent Commits

git log --format="%h %s" --since="1 month ago"

Or from a specific commit:

git log --oneline <commit>..HEAD

Step 3: Filter and Deduplicate

Include only changes users would notice: features, bug fixes, performance improvements.

Skip internal changes: refactors, tests, chore, CI, docs (unless user-facing help docs).

Deduplicate against existing entries. Compare each candidate commit against what's already in the changelog — if a commit is already covered by an existing entry (even with different wording), skip it.

Step 4: Write Entries

Group by category (Features, Improvements, Bug Fixes, Performance). Adapt categories to the project's domain when appropriate, and factor in any optional additional context.

Writing rules:

• Active voice: "Create shareable links" not "Shareable links were added"

• Describe what users can do differently, not how the implementation works — even for technical projects. "Project setup is now smarter and faster" not "Adopted three-tier context model with signal-to-noise scoring"

• Bold the feature name: Feature name - description

• One line per entry

• Combine multiple commits for one feature into a single entry

Step 5: Update CHANGELOG.md

Add a new section at the top (after the header):

Month Year

Category

• Feature name - Brief description

Step 6: Verify

• Only user-facing changes included

• No technical jargon

• Consistent formatting with existing entries

• No duplicates with existing changelog content

Example transformation — feat(auth): add OAuth2 login with Google becomes Google sign-in - Sign in with your Google account for faster access .

Guidelines

• User perspective — ask "Would a user notice or care about this?"

• No duplicates — check existing entries before adding

• Combine related commits — multiple commits for one feature = one entry

• Positive framing — "Fixed X" is better than "X was broken"

Related Skills

Before: Use forge-address-pr-feedback to address reviewer feedback before merging.

Example Usage

/forge-update-changelog /forge-update-changelog 2025-01-01 /forge-update-changelog 2025-01-01 -- emphasize user-visible setup workflow improvements